headers
Julian Reschke | 1 Oct 2008 16:45
Picon
Picon

Re: I-D Action:draft-reschke-webdav-post-00.txt


Ok,

I have a new version ready that (hopefully) addresses all points that 
have been raised so far. See

	<http://greenbytes.de/tech/webdav/draft-reschke-webdav-post-latest.html>

BR, Julian (planning to submit it tomorrow as -01)

Cyrus Daboo wrote:
> 
> Hi Julian,
> 
> --On September 23, 2008 5:46:12 PM +0200 Julian Reschke 
> <julian.reschke <at> gmx.de> wrote:
> 
>>> "When a server supports WebDAV ACL [RFC3744], the DAV:bind privilege is
>>> required to be granted on the collection resource in which the new
>>> member resource is being created. If this privilege is denied or not
>>> present, the POST request MUST fail."
>>
>> Yes, although I'd move that into a "Relation to WebDAV ACL" section.
>>
>>> Another question: there is no restriction on what p:add-member URI can
>>> be? e.g. if I have the collection "/a/b/" can the p:add-member be
>>> another resource entirely, e.g. "/a/use-c-to-create-in-b/"? If this is
>>
>> I thought that was already clear; maybe I should have chosen a different
>> URI :-)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Reschke | 2 Oct 2008 14:13
Picon
Picon

Re: I-D Action:draft-reschke-webdav-post-01.txt


(FYI)

Internet-Drafts <at> ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Using POST to add Members to Web Distributed Authoring and Versioning (WebDAV) Collections
> 	Author(s)       : J. Reschke
> 	Filename        : draft-reschke-webdav-post-01.txt
> 	Pages           : 19
> 	Date            : 2008-10-02
> 
> The Hypertext Transfer Protocol (HTTP) Extensions for the Web
> Distributed Authoring and Versioning (WebDAV) do not define the
> behavior for the "POST" method when applied to collections, as the
> base specification (HTTP) leaves implementers lots of freedom for the
> semantics of "POST".
> 
> This has lead to a situation where many WebDAV servers do not
> implement POST for collections at all, although it is well suited to
> be used for the purpose of adding new members to a collection, where
> the server remains in control of the newly assigned URL.  As a matter
> of fact, the Atom Publishing Protocol (AtomPub) uses POST exactly for
> that purpose.  On the other hand, WebDAV-based protocols such as the
> Calendar Extensions to WebDAV (CalDAV) frequently require clients to
> pick a unique URL, although the server could easily perform that
> task.
> 
> This specification defines a discovery mechanism through which
> servers can advertise support for POST requests with the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 3 Oct 2008 16:15
Picon
Favicon

I-D Action:draft-ietf-webdav-bind-21.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF.

	Title           : Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)
	Author(s)       : G. Clemm, et al.
	Filename        : draft-ietf-webdav-bind-21.txt
	Pages           : 46
	Date            : 2008-10-03

This specification defines bindings, and the BIND method for creating
multiple bindings to the same resource.  Creating a new binding to a
resource causes at least one new URI to be mapped to that resource.
Servers are required to insure the integrity of any bindings that
they allow to be created.Editorial Note (To be removed by RFC Editor
before publication)

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

<http://www.webdav.org/bind/draft-ietf-webdav-bind-issues.html> lists
all registered issues since draft 02.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-21.txt

Internet-Drafts are also available by anonymous FTP at:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Reschke | 3 Oct 2008 16:50
Picon
Picon

Re: I-D Action:draft-ietf-webdav-bind-21.txt


(FYI)

This draft contains just the editorial changes made since November 2007. 
I also added the two issues that I'd like to see resolved before we 
start a new attempt of publishing:

1) Micromanagement of status codes 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-21.html#rfc.issue.status-codes>, 
raises last week), and

2) Relation to DeltaV

(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-21.html#rfc.issue.relation-to-deltav>, 
raised in August by Werner Donné).

BR, Julian

Internet-Drafts <at> ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF.
> 
> 
> 	Title           : Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)
> 	Author(s)       : G. Clemm, et al.
> 	Filename        : draft-ietf-webdav-bind-21.txt
> 	Pages           : 46
> 	Date            : 2008-10-03
> 
> This specification defines bindings, and the BIND method for creating
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Reschke | 4 Oct 2008 19:02
Picon
Picon

Re: Relationship between BIND and RFC 3253


OK,

proposed text (see also 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.relation-to-deltav>):

10.  Relationship to Versioning Extensions to WebDAV

    Servers that implement Version Controlled Collections as defined in
    Section 14 of [RFC3253] already need to implement BIND-like behaviour
    in order to handle UPDATE and UNCHECKOUT semantics.

    Consider the version-controlled, checked-out collections C1 and C2,
    named "/CollX" and "/CollY", and a version-controlled resource R,
    bound to C1 as "/CollX/test":

                          +-------------------------+
                          | Root Collection         |
                          |  bindings:              |
                          |  CollX          CollY   |
                          +-------------------------+
                              |                |
                              |                |
                              |                |
                     +---------------+  +---------------+
                     | Collection C1 |  | Collection C2 |
                     | bindings:     |  |               |
                     |     test      |  |               |
                     +---------------+  +---------------+
                              |
(Continue reading)

Permalink | Reply | 7 comments |
headers
Julian Reschke | 5 Oct 2008 20:11
Picon
Picon

Re: BIND and HTTP status codes


Julian Reschke wrote:
> 
> Hi,
> 
> while implementing WebDAV BIND in Jackrabbit [1] (the Apache Java 
> Content Repository Reference Implementation), my colleague Manfred 
> Baedke noticed that the spec currently micro-manages HTTP status codes: 
> for instance, for a successful BIND it requires status codes of 200 or 
> 201, while - from an HTTP point of view - a 204 should be acceptable as 
> well.
> 
> Proposal: rephrase the text so that other success codes are acceptable 
> as well, or remove the normative language completely, point to RFC2616, 
> and rely on examples.
> 
> BR, Julian
> 
> [1] <https://issues.apache.org/jira/browse/JCR-1733>

Proposed resolution, deliberately kept simple in order not to make 
bigger changes at this stage:

Section 4., paragraph 9:
OLD:

       If the request succeeds, the server MUST return 201 (Created) when
       a new binding was created and 200 (OK) when an existing binding
       was replaced.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Reschke | 7 Oct 2008 14:24
Picon
Picon

Re: Relationship between BIND and RFC 3253


Julian Reschke wrote:
> 
> OK,
> 
> proposed text (see also 
>
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.relation-to-deltav>): 

...in the meantime I realized that this is only true if it happens 
inside a workspace. New version (changing the intro and the paths):

10.  Relationship to Versioning Extensions to WebDAV

    Servers that implement Workspaces ([RFC3253], Section 6) and Version
    Controlled Collections ([RFC3253], Section 14) already need to
    implement BIND-like behaviour in order to handle UPDATE and
    UNCHECKOUT semantics.

    Consider a workspace "/ws1/", containing the version-controlled,
    checked-out collections C1 and C2, named "/ws1/CollX" and "/ws1/
    CollY", and a version-controlled resource R, bound to C1 as "/ws1/
    CollX/test":

                          +-------------------------+
                          | Workspace               |
                          |  bindings:              |
                          |  CollX          CollY   |
                          +-------------------------+
                              |                |
(Continue reading)

Permalink | Reply | 6 comments |
headers
Werner Donné | 7 Oct 2008 14:34
Picon

Re: Relationship between BIND and RFC 3253


Hi Julian,

Why is it only valid inside a workspace?

Best regards,

Werner.

On 07 Oct 2008, at 14:24, Julian Reschke wrote:

> Julian Reschke wrote:
>> OK,
>> proposed text (see also
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.relation-to-deltav 
>> >):
>
> ...in the meantime I realized that this is only true if it happens  
> inside a workspace. New version (changing the intro and the paths):
>
> 10.  Relationship to Versioning Extensions to WebDAV
>
>   Servers that implement Workspaces ([RFC3253], Section 6) and Version
>   Controlled Collections ([RFC3253], Section 14) already need to
>   implement BIND-like behaviour in order to handle UPDATE and
>   UNCHECKOUT semantics.
>
>   Consider a workspace "/ws1/", containing the version-controlled,
>   checked-out collections C1 and C2, named "/ws1/CollX" and "/ws1/
>   CollY", and a version-controlled resource R, bound to C1 as "/ws1/
(Continue reading)

Permalink | Reply | 5 comments |
headers
Julian Reschke | 7 Oct 2008 14:45
Picon
Picon

Re: Relationship between BIND and RFC 3253


Werner Donné wrote:
> 
> Hi Julian,
> 
> Why is it only valid inside a workspace?
> 
> Best regards,
> 
> Werner.

The behavior for UNCHECKOUT on versioned collections isn't described in 
RFC3253, but the errata list 
(<http://www.webdav.org/deltav/protocol/rfc3253-issues-list.htm>) says:

"14_MISSING_ SEMANTICS
	
Editorial
	
Editor
	
The semantics of UNCHECKOUT applied to a version-controlled collection 
is undefined.
	
Julian Reschke: message
	
Define UNCHECKOUT semantics to be those of doing an UPDATE to the 
DAV:checked-out version."

What's relevant is 14.11 (IMHO), which says:
(Continue reading)

Permalink | Reply | 4 comments |
headers
Werner Donné | 7 Oct 2008 15:50
Picon

Re: Relationship between BIND and RFC 3253


There are indeed no additional semantics for UNCHECKOUT in section 14.
Therefore, I think the semantics of section section 4.5 apply, because
a version-controlled collection is also a version-controlled resource.

Though the introduction of section 14 mentions workspaces, I don't think
the merge feature is limited to workspaces. It is allowed to use a
version-controlled collection as the request URI and a collection  
version
as the source. If both would be associated with the same version  
history,
for example, it would be strange if in such a case new version- 
controlled
members would be created as described in section 4.11.

Werner.

On 07 Oct 2008, at 14:45, Julian Reschke wrote:

> Werner Donné wrote:
>> Hi Julian,
>> Why is it only valid inside a workspace?
>> Best regards,
>> Werner.
>
> The behavior for UNCHECKOUT on versioned collections isn't described  
> in RFC3253, but the errata list (<http://www.webdav.org/deltav/protocol/rfc3253-issues-list.htm 
> >) says:
>
> "14_MISSING_ SEMANTICS
(Continue reading)

Permalink | Reply | 3 comments |

Gmane