gmane.ietf.webdav

Re: LOCKing an unmapped URL

Werner Donné — 2013-01-03T22:12:00

Section 9.10.6 of RFC 4918 doesn't mandate those headers to be included, but I don't think it is forbidden to include them. Even when considering the PUT method as an anology, those headers are not obligatory.

Werner.

--
http://www.pincette.biz/
Handling your documents with care, wherever you are.

Op 03 Jan 2013 om 21:59 heeft Ken Murchison <murch< at >andrew.cmu.edu> het volgende geschreven:

LOCKing an unmapped URL

Ken Murchison — 2013-01-03T20:59:04

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?

Re: If header field and conditional precedence

Ken Murchison — 2012-12-25T16:57:03

Hi Julian,

HTTPbis, part 4 already has text stating that extensions need to define 
how additional conditional headers are expected to play with others, 
which is why I brought my question to the WebDAV list.  I can certainly 
take it to the HTTPbis list of you still feel that is the best place.

   "Any extension to HTTP/1.1 that defines additional conditional request
    header fields ought to define its own expectations regarding the
    order for evaluating such fields in relation to those defined in this
    document and other conditionals that might be found in practice."

Re: If header field and conditional precedence

Julian Reschke — 2012-12-25T11:03:09


I would recommend that you re-send to the HTTP mailing list. Are new 
conditional headers an extension point that needs to be described 
specifically? It seems that a specification that registers a new 
conditional header needs needs to define how it interacts with the 
others; and thus we probably should add this to the "considerations for 
new header fields" part...

Best regards, Julian

If header field and conditional precedence

Ken Murchison — 2012-12-23T21:00:46

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:

        *  if true, continue to step 1

        *  if fals

Re: I-D Action: draft-murchison-webdav-prefer-00.txt

Jan Algermissen — 2012-09-28T12:01:18

Ken,

not sure if what I say applies, but it might be a good idea to talk to Erik Wilde and look for synergies regarding his Profile link relation I-D?

Jan

On Sep 28, 2012, at 1:52 PM, Ken Murchison wrote:

Re: Fwd: I-D Action: draft-murchison-webdav-prefer-00.txt

Ken Murchison — 2012-09-28T11:52:21

Folks,

This draft primarily documents what we have done with CalDAV clients and 
servers, but I'd like to make it as general as possible.  It started off 
as documenting the Brief header implemented by Exchange and then morphed 
into using Prefer.


Julian Reschke wrote:

Fwd: I-D Action: draft-murchison-webdav-prefer-00.txt

Julian Reschke — 2012-09-28T11:43:20

(FYI)


-------- Original Message --------
Subject: I-D Action: draft-murchison-webdav-prefer-00.txt
Date: Thu, 27 Sep 2012 14:09:41 -0700
From: internet-drafts< at >ietf.org
Reply-To: internet-drafts< at >ietf.org
To: i-d-announce< at >ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.


Title           : Use of the Prefer Header Field in Web Distributed 
Authoring and Versioning (WebDAV)
Author(s)       : Kenneth Murchison
Filename        : draft-murchison-webdav-prefer-00.txt
Pages           : 26
Date            : 2012-09-27

Abstract:
    This specification defines how the HTTP Prefer header can be used by
    a WebDAV client to request that certain behaviors be implemented by a
    server while constructing a response to a successful request.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-murchison-webdav-prefer

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-murchison-webdav-prefer-00


Internet

Ambiguous example for COPY in RFC 4918

Federico Di Gregorio — 2012-08-29T10:29:26

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 t

Fwd: RFC 6638 on Scheduling Extensions to CalDAV

Julian Reschke — 2012-06-18T09:32:12

(FYI)


-------- Original Message --------
Subject: RFC 6638 on Scheduling Extensions to CalDAV
Date: Sun, 17 Jun 2012 23:25:46 -0700 (PDT)
From: rfc-editor< at >rfc-editor.org
To: ietf-announce< at >ietf.org, rfc-dist< at >rfc-editor.org
CC: rfc-editor< at >rfc-editor.org


A new Request for Comments is now available in online RFC libraries.


         RFC 6638

         Title:      Scheduling Extensions to CalDAV
         Author:     C. Daboo, B. Desruisseaux
         Status:     Standards Track
         Stream:     IETF
         Date:       June 2012
         Mailbox:    cyrus< at >daboo.name,
                     bernard.desruisseaux< at >oracle.com
         Pages:      78
         Characters: 156287
         Updates:    RFC4791, RFC5546

         I-D Tag:    draft-desruisseaux-caldav-sched-12.txt

         URL:        http://www.rfc-editor.org/rfc/rfc6638.txt

This document defines extensions to the Calendaring Extensions to
WebDAV (CalDAV) "calendar-access" feature to specify a standard way
of performing scheduling operations with

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

Julian Reschke — 2012-06-02T09:38:34

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>
         </D:lockentry>
       </D:supportedlock>

Fwd: RFC 6578 on Collection Synchronization for Web Distributed Authoring and Versioning (WebDAV)

Julian Reschke — 2012-03-20T13:09:52

(FYI)

-------- Original Message --------
Subject: RFC 6578 on Collection Synchronization for Web Distributed 
Authoring and Versioning (WebDAV)
Date: Mon, 19 Mar 2012 18:47:28 -0700 (PDT)
From: rfc-editor< at >rfc-editor.org
To: ietf-announce< at >ietf.org, rfc-dist< at >rfc-editor.org
CC: rfc-editor< at >rfc-editor.org


A new Request for Comments is now available in online RFC libraries.


         RFC 6578

         Title:      Collection Synchronization for Web Distributed
                     Authoring and Versioning (WebDAV)
         Author:     C. Daboo, A. Quillaud
         Status:     Standards Track
         Stream:     IETF
         Date:       March 2012
         Mailbox:    cyrus< at >daboo.name,
                     arnaud.quillaud< at >oracle.com
         Pages:      29
         Characters: 55731
         Updates/Obsoletes/SeeAlso:   None

         I-D Tag:    draft-daboo-webdav-sync-08.txt

         URL:        http://www.rfc-editor.org/rfc/rfc6578.txt

This specification defines an extension to Web Distributed Authoring

Re: webDAV apple open source

Jim Luther — 2012-02-10T18:45:28

You're asking your question in the wrong place. This mailing list is for webdav protocol questions and not for specific implementations of a product that uses the WebDAV protocol. You should really direct questions specific to Apple's file system implementations to filesystem-dev< at >lists.apple.com which you can sign up for at <https://lists.apple.com/mailman/listinfo/filesystem-dev>.

However, in this case you're lucky because I used to work on the webdavfs code base (that was about 7 years ago) and I haven't ever unsubscribed from this mailing list.

In Mac OS 10.6 (SnowLeopard), network file system team at Apple unified the authentication/mount GUI for all of the network file systems shipped with the OS. The GUI code is in the NetFS framework, but that code is not public API -- that's why you don't have access to <NetFS/NetFSPrivate.h>. You could argue that those parts of NetFS should be API, but I can't help you with that.

However, you should be able to build the project by commenting out "#include <NetFS/

Re: webDAV apple open source

Syl-J CALIMPUSAN — 2012-02-10T17:12:41

Yes, where can I get the header file NetFSPrivate.h?




On Fri, Feb 10, 2012 at 1:02 AM, <gonzdavid76< at >aol.com> wrote:

webDAV apple open source

Syl-J CALIMPUSAN — 2012-02-09T01:40:23

I am having a hard time compiling the webDAV apple open source codes.  I am
missing NetFS/NetFSPrivate.h header files.  Anyone has access to that file?

Thanks.

Fwd: Protocol Action: 'Collection Synchronization for WebDAV' to Proposed Standard (draft-daboo-webdav-sync-08.txt)

Julian Reschke — 2012-01-31T18:46:48

(FYI)

-------- Original Message --------
Subject: Protocol Action: 'Collection Synchronization for WebDAV' to 
Proposed Standard (draft-daboo-webdav-sync-08.txt)
Date: Mon, 30 Jan 2012 16:13:25 -0800
From: The IESG <iesg-secretary< at >ietf.org>
To: IETF-Announce <ietf-announce< at >ietf.org>
CC: RFC Editor <rfc-editor< at >rfc-editor.org>

The IESG has approved the following document:
- 'Collection Synchronization for WebDAV'
   (draft-daboo-webdav-sync-08.txt) as a Proposed Standard

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Peter Saint-Andre.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-daboo-webdav-sync/




Technical Summary

    This specification defines an extension to WebDAV that allows
    efficient synchronization of the contents of a WebDAV collection.

    WebDAV (RFC 4918) defines the concept of 'collections' which are
    hierarchical groupings of WebDAV resources on an HTTP
    server.  Collections can

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

Cyrus Daboo — 2012-01-19T16:21:57

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

Re: About COPY Overwrite:T Depth:0

Manfred Baedke — 2011-12-21T12:19:30


On 21.12.11 12:14, Javier Godoy wrote:
Not necessarily. I think this is intented to prevent a non-empty 
collection from being overridden by an empty collection. The COPY with 
Depth:0 must fail then.

Regards,
Manfred

Re: About COPY Overwrite:T Depth:0

Javier Godoy — 2011-12-21T11:14:19


It follows that the requirement in Section 9.8.4 does not hold if Depth is 0:
"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."

I agree it looks like an erratum.


Best Regards

Javier

Re: About COPY Overwrite:T Depth:0

Julian Reschke — 2011-12-18T21:58:31

Well, it's seriously defined, but maybe it needs to be clarified.

WRT collections: what exactly is the problem?


Depth: 1 isn't defined in 4918.


I'm losing you.

The spec says:

"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 problem I can see is that if you read this literally, you'd copy the 
bindings to the member resources, which is unlikely to be intended. 
Sounds like an erratum to me.

Do you see other problems?

Best regards, Julian

Re: About COPY Overwrite:T Depth:0

Werner Baumann — 2011-12-18T21:11:47

Copy with Depth: 0 is one of the fancy ideas of RFC 4918 that was never
seriously defined, just as Collection is mostly undefined.
Copy - with or without Overwrite - of collections only makes sense with
Depths: infinity. Depth 0 or 1 will work when the depth of the tree is
0 or 1 in which case you could use Depth infinity as well. Otherwise
you will get orphaned members or mappings to non-existent members. Or
you create a copy of a collection that isn't a copy because it has a
different list of direct members.

Cheers
Werner