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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke

Hi,

I have updated my "POST in WebDAV proposal".

At this point I think it's ready for an informal last call. From my
point of view the remaining questions are:

- is there sufficient community support for this justifying the put the
element names into the DAV: namespace?

and

- should I keep the sections that talk about the HTTP Link header (which
is currently being proposed in an I-D which may or may not be ready
before this proposal is ready)

BR, Julian



[hidden email] 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-02.txt
> Pages           : 15
> Date            : 2008-11-30
>
> 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 led 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
> aforementioned "add collection member" semantics.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-reschke-webdav-post-02.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> I-D-Announce mailing list
> [hidden email]
> 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


Reply | Threaded
Open this post in threaded view
|

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

Geoffrey M Clemm

I support this draft, and believe the element names should be added into the DAV: namespace.

I suggest removing the section that talks about the HTTP Link header, to remove this dependency (or at least, marking it somehow as "to be removed by editor if the HTTP Link I-D is not ready").

Cheers,
Geoff


[hidden email] wrote on 11/30/2008 12:19:00 PM:

>
> Hi,
>
> I have updated my "POST in WebDAV proposal".
>
> At this point I think it's ready for an informal last call. From my
> point of view the remaining questions are:
>
> - is there sufficient community support for this justifying the put the
> element names into the DAV: namespace?
>
> and
>
> - should I keep the sections that talk about the HTTP Link header (which
> is currently being proposed in an I-D which may or may not be ready
> before this proposal is ready)
>
> BR, Julian
>
>
>
> [hidden email] 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-02.txt
> >    Pages           : 15
> >    Date            : 2008-11-30
> >
> > 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 led 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
> > aforementioned "add collection member" semantics.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-reschke-webdav-post-02.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > [hidden email]
> > 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
>
>
Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke

Geoffrey M Clemm wrote:
>
> I support this draft, and believe the element names should be added into
> the DAV: namespace.

Yes, I hear that a lot. It would be good to hear the Apps Area
Director's opinion, though...

> I suggest removing the section that talks about the HTTP Link header, to
> remove this dependency (or at least, marking it somehow as "to be
> removed by editor if the HTTP Link I-D is not ready").

I've rearranged it so it's clear it's optional
(<http://greenbytes.de/tech/webdav/draft-reschke-webdav-post-latest.html>).

Funny enough, in the meantime the Link header was updated as well, so
maybe we can just leave things in.

BR, Julian

Reply | Threaded
Open this post in threaded view
|

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

Lisa Dusseault-3
I have no problem with this draft and with the element names in the "DAV:" namespace.  Depending on what status the community has consensus for, we could either do it as Proposed Standard, or as Informational (or I suppose Experimental) with specific mention of the use of the "DAV:" namespace.

It now seems we're working towards a major update of WebDAV with a bunch of features we may want to push into the core requirements.  Not necessarily next year or the year after, just something to start thinking about once we've had experience with things like MKCOL bodies and POST to create.  I've also had pings recently about property synchronization and collection synch tags.

Lisa

On Mon, Dec 1, 2008 at 8:49 AM, Julian Reschke <[hidden email]> wrote:

Geoffrey M Clemm wrote:

I support this draft, and believe the element names should be added into the DAV: namespace.

Yes, I hear that a lot. It would be good to hear the Apps Area Director's opinion, though...


I suggest removing the section that talks about the HTTP Link header, to remove this dependency (or at least, marking it somehow as "to be removed by editor if the HTTP Link I-D is not ready").

I've rearranged it so it's clear it's optional (<http://greenbytes.de/tech/webdav/draft-reschke-webdav-post-latest.html>).

Funny enough, in the meantime the Link header was updated as well, so maybe we can just leave things in.

BR, Julian


Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke

Lisa Dusseault wrote:
> I have no problem with this draft and with the element names in the
> "DAV:" namespace.  Depending on what status the community has consensus
> for, we could either do it as Proposed Standard, or as Informational (or
> I suppose Experimental) with specific mention of the use of the "DAV:"
> namespace.

I'm happy with Experimental; but if other specs on the Standards Track
want to use it we'll have to progress it to Proposed anyway.

So I'll wait for some more feedback, and then submit something
reflecting that at the end of this week.

> It now seems we're working towards a major update of WebDAV with a bunch
> of features we may want to push into the core requirements.  Not
> necessarily next year or the year after, just something to start
> thinking about once we've had experience with things like MKCOL bodies
> and POST to create.  I've also had pings recently about property
> synchronization and collection synch tags.
>
> Lisa

Indeed. Maybe we need WebDAVbis at some point in the future.

More ideas:

- extract REPORT method and some of the discovery mechanisms out of
RFC3253 for easier re-use

- revise ACL

- augment safe methods such as PROPFIND, REPORT and SEARCH with GETable
representations (allowing simple addressing, caching and conditional
requests)

- do some work on mapping JCR (Java Content Repository) features onto
WebDAV, such as multivalued properties (currently lacking in RFC 4316)
and resource types (aka node types in JCR)

- look into peaceful co-existence with AtomPub (:-)

BR, Julian

Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
In reply to this post by Lisa Dusseault-3

Lisa Dusseault wrote:
> I have no problem with this draft and with the element names in the
> "DAV:" namespace.  Depending on what status the community has consensus
> for, we could either do it as Proposed Standard, or as Informational (or
> I suppose Experimental) with specific mention of the use of the "DAV:"
> namespace.
> ...

Does this:

       Note: this specification defines new properties and precondition
       names in the "DAV:" namespace, which the WebDAV specification
       reserves for use by the IETF ([RFC4918], Section 21.1).  However,
       there was rough consensus in the WebDAV community that it is of
       general applicability to other WebDAV related standards efforts,
       and thus deserves inclusion into the base namespace.

sound ok?
(<http://greenbytes.de/tech/webdav/draft-reschke-webdav-post-latest.html#terminology>)

BR, Julian

Reply | Threaded
Open this post in threaded view
|

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

Lisa Dusseault-3


On Tue, Dec 2, 2008 at 10:21 AM, Julian Reschke <[hidden email]> wrote:
     Note: this specification defines new properties and precondition
     names in the "DAV:" namespace, which the WebDAV specification
     reserves for use by the IETF ([RFC4918], Section 21.1).  However,
     there was rough consensus in the WebDAV community that it is of
     general applicability to other WebDAV related standards efforts,
     and thus deserves inclusion into the base namespace.

sound ok? (<http://greenbytes.de/tech/webdav/draft-reschke-webdav-post-latest.html#terminology>)

Yes, that would work. Pedantically speaking, though, replace the "it" in line 4 with "the specification" otherwise it refers to the last-used noun, "the WebDAV community"  :)

Lisa
Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
In reply to this post by Julian Reschke

Julian Reschke wrote:

>
> Hi,
>
> I have updated my "POST in WebDAV proposal".
>
> At this point I think it's ready for an informal last call. From my
> point of view the remaining questions are:
>
> - is there sufficient community support for this justifying the put the
> element names into the DAV: namespace?

I heard two "yes" votes (one on which from one of our Area Directory),
an no "no".

So the next draft will use the DAV: namespace.

> and
>
> - should I keep the sections that talk about the HTTP Link header (which
> is currently being proposed in an I-D which may or may not be ready
> before this proposal is ready)

For now I'll leave this out; instead, when the Link header spec is done
I'll propose a document specifying how to map link-typed DAV properties
to Link headers in general (see proposal in
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2008OctDec/0026.html>).

BR, Julian


Reply | Threaded
Open this post in threaded view
|

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

Cyrus Daboo-2

Hi Julian,

--On December 6, 2008 10:27:18 PM +0100 Julian Reschke
<[hidden email]> wrote:

>> - is there sufficient community support for this justifying the put the
>> element names into the DAV: namespace?
>
> I heard two "yes" votes (one on which from one of our Area Directory), an
> no "no".
>
> So the next draft will use the DAV: namespace.

Additional +1.

>> and
>>
>> - should I keep the sections that talk about the HTTP Link header (which
>> is currently being proposed in an I-D which may or may not be ready
>> before this proposal is ready)
>
> For now I'll leave this out; instead, when the Link header spec is done
> I'll propose a document specifying how to map link-typed DAV properties
> to Link headers in general (see proposal in
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2008OctDec/0026.html>).

That seems reasonable.

--
Cyrus Daboo


Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
In reply to this post by Julian Reschke

Julian Reschke wrote:
> ...
> I heard two "yes" votes (one on which from one of our Area Directory),
> an no "no".
> ...

Oh well.

s/Directory/Directors/

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Last Calling webdav-post draft, Re: I-D Action:draft-reschke-webdav-post-02.txt

Julian Reschke
In reply to this post by Julian Reschke

Julian Reschke wrote:

>
> Julian Reschke wrote:
>>
>> Hi,
>>
>> I have updated my "POST in WebDAV proposal".
>>
>> At this point I think it's ready for an informal last call. From my
>> point of view the remaining questions are:
>>
>> - is there sufficient community support for this justifying the put
>> the element names into the DAV: namespace?
>
> I heard two "yes" votes (one on which from one of our Area Directory),
> an no "no".
>
> So the next draft will use the DAV: namespace.
>
>> and
>>
>> - should I keep the sections that talk about the HTTP Link header
>> (which is currently being proposed in an I-D which may or may not be
>> ready before this proposal is ready)
>
> For now I'll leave this out; instead, when the Link header spec is done
> I'll propose a document specifying how to map link-typed DAV properties
> to Link headers in general (see proposal in
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2008OctDec/0026.html>).
>
> BR, Julian

So I made the two changes announced above, and submitted it as
draft-reschke-webdav-post-03.

At this point I think this is stable, and therefore would like to give
the WebDAV community four weeks for review (*), until I'll ask Lisa
Dusseault to process this as an individual submission.

BR, Julian

(*) because of the holidays


Reply | Threaded
Open this post in threaded view
|

Re: Last Calling webdav-post draft, Re: I-D Action:draft-reschke-webdav-post-02.txt

Julian Reschke

Hi,

I received feedback from Cyrus in private mail, but follow up over here
to that the discussion gets properly archived.

Cyrus Daboo wrote:

>> Hi Cyrus,
>>
>> thanks for the feedback. More inline.
>>
>>> In reviewing this for the write-up I have a couple of comments:
>>>
>>> 1) Section 3.2.1 - in the WebDAV spec I am writing I am following the
>>> "template" used in 4918 for definition of new WebDAV properties. I find
>>> using that promotes consistency and completeness in the definition. I
>>> would prefer that the definition in 3.2.1 follow that template.
>>
>> I personally find that template sub-optimal because it leads to
>> repetition. Also the COPY/MOVE category should IMHO only be used when
>> it's a special case; otherwise we'll see lots of new behaviors made up
>> when they do not really make sense.
>>
>> In this particular case, though, I'll have to add a statement that the
>> property is protected.
>
>>> From an implementation standpoint I find it useful to know what should
> happen in a COPY/MOVE, though for the most part for live properties it
> is not really relevant.

For now I just have added the statement that the property is protected
(<http://greenbytes.de/tech/webdav/draft-reschke-webdav-post-latest.html#rfc.issue.protected>).
The behavior for COPY/MOVE IMHO directly follows from its semantics, the
same was other most live properties happen to behave.

>>> 4) Section 8 - given the stated security concern of an attacker tricking
>>> a client to use add-member on a server not supporting it, wouldn't it be
>>> better for a server to explicitly identify support for this extension
>>> via the DAV header? That way clients know from that whether the
>>> add-member property will be valid or not. I generally prefer advertising
>>> capabilities up-front like this rather than requiring clients to probe
>>> the server in some fashion to see what is supported. Given that this is
>>> a security concern I think being explicit about support for the
>>> extension would be good.
>>
>> I'm not a big fan of adding new compliance classes when they aren't
>> absolutely needed; in particular because it means another round trip (the
>> classes can vary per resource after all).
>
> How about adding:
>
> "When retrieving the DAV:add-member property on a collection resource,
> clients MUST also retrieve the DAV:supported-live-property-set property
> and verify that the DAV:add-member property is listed there. If
> DAV:add-member is not listed in DAV:supported-live-property-set, then
> clients MUST NOT use any DAV:add-member value as the target of a POST
> request to create a new resource."

Actually, the Security Considerations already say:

"In addition, on servers that do not support this specification, a
malevolent user could set the DAV:add-member URI as a custom property,
tricking other users to post content to an entirely different URI.
Clients can protect themselves against this scenario by

     * not following DAV:add-member URIs to different servers, and/or
     * verifying that the DAV:add-member property is indeed a live
property (this can be achieved by testing the
DAV:supported-live-property-set property, or by checking whether
DAV:add-member is returned upon PROPFIND/allprop)." --
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-post-latest.html#security.considerations>

> ...
>>> 5) MKCOL - in Section 4 you state that servers may restrict use of MKCOL
>>> in a collection. But it is not clear how POST + add-member can be used
>>> as a substitute for MKCOL. i.e., what would the POST body look like for
>>> creation of a server-named collection?
>>
>> There isn't any. If we leave things they are we should state that this is
>> a restriction.
>>> 6) Section 4 - same issue as for MKCOL for COPY/MOVE. If a server
>>> refuses a COPY/MOVE that creates a new resource, how does the client
>>> actually use DAV:add-member to trigger the equivalent behavior? The
>>> client should not need to send the data of the original resource in the
>>> POST in order to create the new one. That certainly wouldn't work when a
>>> collection is being moved. So what should happen here?
>>
>> Again: out of scope.
>
> OK, then I suggest you remove MKCOL, COPY and MOVE from Section 4.
> Perhaps even be explicit up front that this extension only deals with
> the case of new resource (non-collection) creation using PUT and that
> MKCOL, COPY and MOVE behavior is not defined here (though could be
> defined by a later extension if there is demand for it).

I have added prose in two places clarifying that this can be used in
place for PUT, but not the other methods. I've left the other text
intact, as the precondition that is defined here indeed applies to all
these methods:
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-post-latest.html#rfc.issue.put-only>.

> ...

Best regards, Julian