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 false, respond 412 (Precondition Failed)

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

    ...

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-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce< at >ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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 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

/container/
/container/R1
/container/R2/
/container/R2/A

into

/othercontainer/
/othercontainer/R2/
/othercontainer/R2/X

and R2 is locked, the final layout is:

/othercontainer/R1
/othercontainer/R2/
/othercontainer/R2/X

Isn't this the opposite of the behaviour specified in 9.8.4? Did we
interpret the example the wrong way? What is the supposed behaviour if
the resources are as in the example above?

Thank you very much fir your time,

federico

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 iCalendar-based calendar
components.  This document defines the "calendar-auto-schedule"
feature of CalDAV.  [STANDARDS-TRACK]

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
   http://www.ietf.org/mailman/listinfo/ietf-announce
   http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor< at >rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

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>
       <D:getcontentlength>7248</D:getcontentlength>
     </D:prop>
     <D:status>HTTP/1.1 200 OK</D:status>
   </D:propstat>
</D:response>

So the response element contains a top-level DAV:href for the URI for of 
the resource:

   <D:href>/foo/bar.txt</D:href>

...but also a nested...

       <C:linked-from xmlns:C="http://example.com/ns">
         <D:href>/qux</D:href>
       </C:linked-from>

inside D:propstat/D:prop.

The client apparently gets confused and uses the second DAV:href 
element; causing a wrong name to be displayed (and likely the wrong 
resource to be used when opened).

Best regards, Julian

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
and Versioning (WebDAV) that allows efficient synchronization of the
contents of a WebDAV collection.  [STANDARDS-TRACK]

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
   http://www.ietf.org/mailman/listinfo/ietf-announce
   http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor< at >rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

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/NetFSPrivate.h>" and modify the code that gets the credentials from NetFS. You'll lose the GUI for getting credentials. Another alternative would be to get the older webdavfs sources (pre-10.6) to see how it implemented the GUI for credentials and then spend a bunch of time bringing those changes to the current source base.

That said, the reason we made the webdavfs source code open was as example code for programmers wanting to implement their own file systems for Mac OS. The source code wasn't published so that programmers could modify it and build it.

Good luck,
Jim

On Feb 10, 2012, at 9:12 AM, Syl-J CALIMPUSAN <syljcalimpusan< at >gmail.com> wrote:

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 be of arbitrary size and depth (i.e.,
    collections within collections).  WebDAV clients that cache resource
    content need a way to synchronize that data with the server (i.e.,
    detect what has changed and update their cache).  This can currently
    be done using a WebDAV PROPFIND request on a collection to list all
    members of a collection along with their DAV:getetag property values,
    which allows the client to determine which were changed, added or
    deleted.  However, this does not scale well to large collections as
    the XML response to the PROPFIND request will grow with the
    collection size.

    This specification defines a new WebDAV report that results in the
    server returning to the client only information about those member
    URIs that were added or deleted, or whose mapped resources were
    changed, since a previous execution of the report on the collection.

    Additionally, a new property is added to collection resources that is
    used to convey a "synchronization token" that is guaranteed to change
    when the collection's member URIs or their mapped resources have
    changed.

Working Group Summary

    This document is not the product of a working group.  However, it
    has been discussed on the w3c-dist-auth< at >w3.org and reviewed
    among implementers in the calendaring and scheduling community.
    Consensus was quite smooth.  There was some slight controversy
    about whether servers should be allowed to return reports with a
    depth of infinity, but that issue was decided in the positive because
    some implementers have uses for such reporting.

Document Quality

    There are several independent implementations (mostly email clients
    and calendaring applications).

Personnel

    The Document Shepherd / Responsible Area Director is
    Peter Saint-Andre.

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 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 ----------

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