idnits 2.17.1 draft-reschke-webdav-post-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 788. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 799. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 806. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 812. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2, 2008) is 5684 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Reschke 3 Internet-Draft greenbytes 4 Intended status: Standards Track October 2, 2008 5 Expires: April 5, 2009 7 Using POST to add Members to Web Distributed Authoring and Versioning 8 (WebDAV) Collections 9 draft-reschke-webdav-post-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 5, 2009. 36 Abstract 38 The Hypertext Transfer Protocol (HTTP) Extensions for the Web 39 Distributed Authoring and Versioning (WebDAV) do not define the 40 behavior for the "POST" method when applied to collections, as the 41 base specification (HTTP) leaves implementers lots of freedom for the 42 semantics of "POST". 44 This has lead to a situation where many WebDAV servers do not 45 implement POST for collections at all, although it is well suited to 46 be used for the purpose of adding new members to a collection, where 47 the server remains in control of the newly assigned URL. As a matter 48 of fact, the Atom Publishing Protocol (AtomPub) uses POST exactly for 49 that purpose. On the other hand, WebDAV-based protocols such as the 50 Calendar Extensions to WebDAV (CalDAV) frequently require clients to 51 pick a unique URL, although the server could easily perform that 52 task. 54 This specification defines a discovery mechanism through which 55 servers can advertise support for POST requests with the 56 aforementioned "add collection member" semantics. 58 Editorial Note (To be removed by RFC Editor before publication) 60 Please send comments to the Distributed Authoring and Versioning 61 (WebDAV) working group at , which may be 62 joined by sending a message with subject "subscribe" to 63 . Discussions of the WEBDAV 64 working group are archived at 65 . 67 Note that although discussion takes place on the WebDAV working 68 group's mailing list, this is not a working group document. 70 XML versions, latest edits and the issues list for this document are 71 available from 72 . 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 3. Protocol Extension . . . . . . . . . . . . . . . . . . . . . . 6 79 3.1. Definition of 'Add-Member' URI . . . . . . . . . . . . . . 6 80 3.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 7 81 3.2.1. p:add-member Property . . . . . . . . . . . . . . . . 7 82 3.2.2. Example . . . . . . . . . . . . . . . . . . . . . . . 7 83 3.2.3. add-member Link Relation . . . . . . . . . . . . . . . 8 84 3.3. Relation to AtomPub's 'Slug' Header . . . . . . . . . . . 9 85 3.4. Example Operation . . . . . . . . . . . . . . . . . . . . 9 86 4. Additional Semantics for existing Methods . . . . . . . . . . 9 87 4.1. Additional Preconditions . . . . . . . . . . . . . . . . . 10 88 4.2. Example: Failed PUT Request . . . . . . . . . . . . . . . 10 89 5. Relationship to WebDAV Access Control Protocol . . . . . . . . 10 90 6. Internationalization Considerations . . . . . . . . . . . . . 11 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 94 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 95 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 96 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 97 Appendix A. Change Log (to be removed by RFC Editor before 98 publication) . . . . . . . . . . . . . . . . . . . . 13 99 A.1. since draft-reschke-webdav-post-00 . . . . . . . . . . . . 13 100 Appendix B. Resolved issues (to be removed by RFC Editor 101 before publication) . . . . . . . . . . . . . . . . . 13 102 B.1. rational-server-uri . . . . . . . . . . . . . . . . . . . 13 103 B.2. remote-uri . . . . . . . . . . . . . . . . . . . . . . . . 14 104 B.3. post-error-semantics . . . . . . . . . . . . . . . . . . . 14 105 B.4. uri-uniqueness . . . . . . . . . . . . . . . . . . . . . . 14 106 B.5. uri-format . . . . . . . . . . . . . . . . . . . . . . . . 15 107 B.6. property-trust . . . . . . . . . . . . . . . . . . . . . . 15 108 B.7. forbidden-put . . . . . . . . . . . . . . . . . . . . . . 15 109 B.8. acl . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 110 B.9. member-uri-content . . . . . . . . . . . . . . . . . . . . 16 111 Appendix C. Open issues (to be removed by RFC Editor prior to 112 publication) . . . . . . . . . . . . . . . . . . . . 17 113 C.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 114 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 115 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 116 Intellectual Property and Copyright Statements . . . . . . . . . . 19 118 1. Introduction 120 The Hypertext Transfer Protocol (HTTP) Extensions for the Web 121 Distributed Authoring and Versioning (WebDAV) ([RFC4918], Section 122 9.5) do not define the behavior for the "POST" method when applied to 123 collections, as the base specification (HTTP) leaves implementers 124 lots of freedom for the semantics of "POST": 126 9.5 POST for Collections 128 Since by definition the actual function performed by POST is 129 determined by the server and often depends on the particular 130 resource, the behavior of POST when applied to collections cannot 131 be meaningfully modified because it is largely undefined. Thus, 132 the semantics of POST are unmodified when applied to a collection. 134 This has lead to a situation where many WebDAV servers do not 135 implement POST for collections at all, although it is well suited to 136 be used for the purpose of adding new members to a collection, where 137 the server remains in control of the newly assigned URL. As a matter 138 of fact, the Atom Publishing Protocol (AtomPub) uses POST exactly for 139 that purpose ([RFC5023], Section 9.2): 141 9.2 Creating Resources with POST 143 To add members to a Collection, clients send POST requests to the 144 URI of the Collection. 146 On the other hand, WebDAV-based protocols such as Calendaring 147 Extensions to WebDAV (CalDAV) frequently require clients to pick a 148 unique URL, although the server could easily perform that task 149 ([RFC4791], Section 5.3.2): 151 5.3.2 Creating Calendar Object Resources 153 ... 155 When servers create new resources, it's not hard for the server to 156 choose an unmapped URI. It's slightly tougher for clients, 157 because a client might not want to examine all resources in the 158 collection and might not want to lock the entire collection to 159 ensure that a new resource isn't created with a name collision. 160 (...) 162 As a matter of fact, letting the server choose the member URI not 163 only is a simplification for certain types of clients, but can also 164 reduce the complexity of the server (in that it doesn't need to 165 persist an additional client-supplied identifier where it already has 166 an internal one like a UUID or a primary key). 168 Note: the vCard Extensions to WebDAV (CardDAV) 169 ([draft-ietf-vcarddav-carddav]) suffer from the same issue, and 170 may be able to take advantage of this specification. 172 This specification defines a discovery mechanism through which 173 servers can advertise support for POST requests with the 174 aforementioned "add collection member" semantics. 176 Note: the author previously proposed a new HTTP method for exactly 177 this purpose ([draft-reschke-http-addmember]), but quite a few 178 reviewers pointed out that this would duplicate the original 179 semantics of POST. Thus this proposal that avoids adding a new 180 HTTP method. 182 2. Terminology 184 The terminology used here follows that in the WebDAV specification 185 ([RFC4918]). 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 189 document are to be interpreted as described in [RFC2119]. 191 This document uses XML DTD fragments ([XML]) as a purely notational 192 convention. In particular: 194 o Element names use the namespace 195 "http://purl.org/NET/webdav/post#". When an XML element type in 196 this namespace is referenced in this document outside of the 197 context of an XML fragment, the string "p:" will be prefixed to 198 the element name. [[ns: With sufficient support from the WebDAV 199 WG's former mailing list and/or the IESG Applications Area the 200 property defined later on could potentially be moved into the DAV: 201 namespace.]] 203 o Element ordering is irrelevant. 205 o Extension elements/attributes (elements/attributes not already 206 defined as valid child elements) may be added anywhere, except 207 when explicitly stated otherwise. 209 3. Protocol Extension 211 Due to the reasons stated in Section 1, clients can not rely on a 212 specific server behavior when POST is applied to a collection. This 213 problem is addressed by this specification by allowing servers to 214 advertise a URI that has the desired "add member" semantics. 216 Note that servers that already use POST for a different purpose can 217 just expose a different URI for that purpose. Other servers can just 218 advertise the collection's own URI, thus avoiding minting another URI 219 for a limited purpose. 221 3.1. Definition of 'Add-Member' URI 223 The "Add-Member" URI of a WebDAV collection is a URI that will accept 224 HTTP POST requests, and will interpret these as requests to store the 225 enclosed entity as a new internal member of the collection. It MUST 226 identify a resource on the same server as the WebDAV collection (the 227 host and port components ([RFC2616], Section 3.2.2) of the URIs must 228 match). 230 If there are pre-conditions related to creating a resource in the 231 collection using a PUT request, then those same pre-conditions apply 232 to the new POST request behavior, and the same HTTP response body 233 will returned on failure. 235 The URI of the newly created resource is returned in the HTTP 236 Location response header ([RFC2616], Section 14.30). 238 Note: the fact that a server advertises an "Add-Member" URI does 239 not imply any special semantics of the collection itself. For 240 instance, member URIs assigned by the server are not necessarily 241 unique over time (a member URI may be assigned again to a new 242 resource when it previously was removed). 244 Note: the "Add-Member" URI can be the identical to the 245 collection's URI (in which case the server just advertises the 246 fact that POST to the WebDAV collection's URI is supported as 247 defined within this specification). But it can also be different 248 from it, in which case it doesn't need to have any relation to the 249 collection's URI. 251 Given a collection URI of 253 /docs/collection/ 255 all of the URIs below might occur as "Add-Member" URIs: 257 /docs/collection/ 258 /docs/collection/;post 259 /docs/collection;post/ 260 /docs/collection/&post 261 /post-service?path=/collection/ 263 The remainder of the document uses the same format just for 264 reasons of consistency; any other HTTP URI would do as well. 266 3.2. Discovery 268 3.2.1. p:add-member Property 270 The p:add-member property is defined on WebDAV collections, and 271 contains the "Add-Member" URI for that collection (embedded inside a 272 DAV:href element). 274 275 277 A PROPFIND/allprop request SHOULD NOT return this property (see 278 [RFC4918], Section 9.1). Servers MUST implement the DAV:supported- 279 live-property-set property defined in Section 3.1.4 of [RFC3253], and 280 report the property p:add-member as a supported live property. 282 3.2.2. Example 284 >>Request 286 PROPFIND /collection/ HTTP/1.1 287 Host: example.com 288 Content-Type: application/xml; charset="utf-8" 289 Content-Length: 163 291 292 293 294 295 296 297 >>Response 299 HTTP/1.1 207 Multi-Status 300 Content-Type: application/xml; charset="utf-8" 301 Content-Length: 385 303 304 305 306 /collection/ 307 308 309 310 /collection;add-member/ 311 312 313 HTTP/1.1 200 OK 314 315 316 317 Note that in this case, the server has minted a separate URI for the 318 purpose of adding new content. 320 3.2.3. add-member Link Relation 322 There may be cases in which it is more efficient to expose the Add- 323 Member URI in HTTP headers or in (X)HTML content. For this use case, 324 this specification defines a new link relation with the name: 326 http://purl.org/NET/webdav/post#add-member 328 It can be used both in HTTP Link headers (see 329 [draft-nottingham-http-link-header]): 331 >>Request 333 HEAD /collection/ HTTP/1.1 334 Host: example.com 336 >>Response 338 HTTP/1.1 200 OK 339 Link: ; 340 rel="http://purl.org/NET/webdav/post#add-member" 342 ...and in (X)HTML content: 344 345 346 Contents of /collection/ 347 349 ... 351 353 3.3. Relation to AtomPub's 'Slug' Header 355 In the AtomPub protocol, clients can use the entity header "Slug" to 356 suggest parts of the URI to be created (see [RFC5023], Section 9.7). 357 Note that servers are free to ignore this suggestion, or to use 358 whatever algorithm that makes sense to generate the new URI. 360 The same applies to the extension defined here: clients can use the 361 "Slug" header as by its definition of a generic HTTP header. Servers 362 should process it exactly the way defined by AtomPub. 364 3.4. Example Operation 366 >>Request 368 POST /collection;add-member/ HTTP/1.1 369 Host: example.com 370 Content-Type: text/plain 371 Slug: Sample Text 372 Content-Length: 12 374 Sample text. 376 >>Response 378 HTTP/1.1 201 Created 379 Location: http://example.com/collection/sample%20text 381 4. Additional Semantics for existing Methods 383 One important use case for this specification are collections that 384 act as WebDAV collections for the purpose of read access (PROPFIND 385 Depth 1/Infinity), but which only support internal member URIs 386 assigned by the server. These collections will not allow a client to 387 create a new member using methods like PUT, MKCOL, LOCK, COPY or 388 MOVE. Therefore, this specification defines a new precondition name 389 ([RFC4918], Section 16) that can be used to provide the client with 390 additional information about why exactly the request failed. 392 4.1. Additional Preconditions 394 (p:allow-client-defined-URI): the server allows clients to specify 395 the last path segment for newly created resources. 397 The precondition element MAY contain a p:add-member-uri XML element 398 specifying the "Add-Member" URI associated with the collection, on 399 which the creation of a new child resource was attempted: 401 403 4.2. Example: Failed PUT Request 405 In this example, the client tries to use PUT to create a new internal 406 member of /collection/. 408 >>Request 410 PUT /collection/new.txt HTTP/1.1 411 Host: example.com 412 Content-Type: text/plain 413 Content-Length: 12 415 Sample text. 417 >>Response 419 HTTP/1.1 405 Method Not Allowed 420 Allow: GET, HEAD, TRACE, PROPFIND, COPY, MOVE 421 Content-Type: application/xml; charset=UTF-8 422 Content-Length: 223 424 425 426 427 /collection;add-member/ 428 429 430 432 The request fails with a 405 (Method Not Allowed) status, but also 433 provides the reason, and a pointer to the "Add-Member" URI in the 434 response body. 436 5. Relationship to WebDAV Access Control Protocol 438 The WebDAV ACL specification requires the DAV:bind privilege to be 439 granted on a collection for the client to able add new collection 440 members ([RFC3744], Section 3.9). Consistent with that, a server 441 MUST reject a POST request to the Add-Member URI of a collection 442 unless the authenticated principal is granted DAV:bind privilege on 443 the associated WebDAV collection resource. 445 6. Internationalization Considerations 447 This document does not introduce any new internationalization 448 considerations beyond those discussed in Section 20 of [RFC4918]. 450 7. IANA Considerations 452 This specification does not require any actions from IANA. 454 8. Security Considerations 456 All security considerations connected to HTTP/WebDAV and XML apply 457 for this specification as well, namely, [RFC4918] (Section 20) and 458 [RFC3470] (Section 7). 460 Furthermore, servers should be aware that deriving the member path 461 from the data being stored in the resource could potentially expose 462 confidential information. This could even be the case when only a 463 hash code of the content is used. 465 In addition, on servers that do not support this specification, a 466 malevolent user could set the p:add-member URI as a custom property, 467 tricking other users to post content to an entirely different URI. 468 Clients can protect themselves against this scenario by 470 o not following p:add-member URIs to different servers, and/or 472 o verifying that the p:add-member property is indeed a live property 473 (this can be achieved by testing the DAV:supported-live-property- 474 set property, or by checking whether p:add-member is returned upon 475 PROPFIND/allprop) 477 9. Acknowledgements 479 This document has benefited from thoughtful discussion by Cyrus Daboo 480 and Bernard Desruissaux. 482 10. References 484 10.1. Normative References 486 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 487 Requirement Levels", BCP 14, RFC 2119, March 1997. 489 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 490 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 491 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 493 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. 494 Whitehead, "Versioning Extensions to WebDAV", RFC 3253, 495 March 2002. 497 [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web 498 Distributed Authoring and Versioning (WebDAV) Access 499 Control Protocol", RFC 3744, May 2004. 501 [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed 502 Authoring and Versioning (WebDAV)", RFC 4918, June 2007. 504 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 505 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth 506 Edition)", W3C REC-xml-20060816, August 2006, 507 . 509 [draft-nottingham-http-link-header] 510 Nottingham, M., "HTTP Header Linking", 511 draft-nottingham-http-link-header-02 (work in progress), 512 July 2008. 514 10.2. Informative References 516 [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for 517 the Use of Extensible Markup Language (XML) within IETF 518 Protocols", RFC 3470, BCP 70, January 2003. 520 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 521 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 522 March 2007. 524 [RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing 525 Protocol", RFC 5023, October 2007. 527 [draft-ietf-vcarddav-carddav] 528 Daboo, C., "vCard Extensions to WebDAV (CardDAV)", 529 draft-ietf-vcarddav-carddav-01 (work in progress), 530 July 2008. 532 [draft-reschke-http-addmember] 533 Reschke, J., "The HTTP ADDMEMBER Method", 534 draft-reschke-http-addmember-00 (work in progress), 535 February 2005. 537 Appendix A. Change Log (to be removed by RFC Editor before publication) 539 A.1. since draft-reschke-webdav-post-00 541 Added Acknowledgements. 543 Add and resolve issues "acl", "forbidden-put", "member-uri-content", 544 "post-error-semantics", "property-trust", "rational-server-uri", 545 ""remote-uri", "uri-format" and "uri-uniqueness". 547 Appendix B. Resolved issues (to be removed by RFC Editor before 548 publication) 550 Issues that were either rejected or resolved in this version of this 551 document. 553 B.1. rational-server-uri 555 In Section 1: 557 Type: change 559 562 cyrus@daboo.name (2008-09-22): One thing this reminds me of: another 563 reason why this POST may be needed is if the server enforces a 564 particular naming scheme on members. e.g., a CalDAV server may 565 require that all member path segments match the UID in the calendar 566 data, or match a record-id in its data store etc. In this case the 567 add-member behavior is required. So its not just the case of "the 568 client doesn't care to name members itself", but also this other one. 569 Probably worth adding a comment on this. 571 Resolution (2009-09-23): Mention that this can simplify the server by 572 not having to persist a client-supplied name. 574 B.2. remote-uri 576 In Section 3.1: 578 Type: change 580 julian.reschke@greenbytes.de (2008-09-30): Explicitly forbid Add- 581 Member URIs pointing to other servers, mainly for reasons of security 582 (DOS), but also for practical reasons (authentication). 584 Resolution (2008-10-01): Require that the "Add-Member" URI points to 585 the same server. 587 B.3. post-error-semantics 589 In Section 3.1: 591 Type: change 593 596 cyrus@daboo.name (2008-09-22): Something needs to be stated about 597 error handling: e.g., "If there are pre-conditions related to 598 creating a resource in the collection using a PUT request, then those 599 same pre-conditions apply to the new POST request behavior, and the 600 same DAV:error response body returned on failure". This would be a 601 "catch-all" to allow protocols such as CalDAV, which restrict certain 602 aspects of the data stored in collections, to simply return the same 603 pre-condition failure information for POST as for PUT. 605 Resolution (2009-09-23): Adopt most of the proposed text, except for 606 saying "HTTP response" to make it more generic (for instance, there 607 may be no DAV:error entity body involved). 609 B.4. uri-uniqueness 611 In Section 3.1: 613 Type: change 615 618 cyrus@daboo.name (2008-09-22): Is the server allowed to re-use new 619 member URIs? i.e. /a/b.txt exists at some point, then is deleted. Is 620 the server then allowed to use b.txt as a new member of /a/, or does 621 the new member path segment have to be unique for the entire 622 existence of that collection? If the member path segment is expected 623 to be unique there should be some guidance to servers on how they 624 might implement that (uuid's for instance). 626 Resolution (2009-09-23): Clarified that this specification doesn't 627 make any additional requirements on the collection semantics. 629 B.5. uri-format 631 In Section 3.1: 633 Type: change 635 638 cyrus@daboo.name (2008-09-23): Another question: there is no 639 restriction on what p:add-member URI can be? e.g. if I have the 640 collection "/a/b/" can the p:add-member be another resource entirely, 641 e.g. "/a/use-c-to-create-in-b/"? If this is possible it should be 642 called out, as the behavior might be somewhat unexpected for clients. 643 It might even be the case that the p:add-member URI is on a different 644 server (e.g. new member items in a collection need "approval" from 645 some other service). The interaction with WebDAV ACL in this case 646 would need to be clear - i.e. what privileges are required on the 647 p:add-member URI? 649 Resolution (2008-09-30): Add a set of examples, and use 650 "/collection;add-member/" in subsequent examples. 652 B.6. property-trust 654 In Section 3.2.1: 656 Type: change 658 julian.reschke@greenbytes.de (2008-10-01): An attacker could set 659 p:add-member as dead property and thus trick clients into POSTing new 660 content somewhere else. 662 Resolution (2008-10-01): (1) Require server support for DAV: 663 supported-live-property-set; (2) mention issue in security 664 considerations. 666 B.7. forbidden-put 668 Type: change 669 672 cyrus@daboo.name (2008-09-23): So one option for the server to 673 enforce its naming scheme would be to require POST by the client to 674 create new resources rather than allowing PUT/COPY/MOVE to do so. 675 However there is no way fort a client to discover that such a 676 restriction might be in place other than getting a 403. How about a 677 new pre-condition code for that so that the server can indicate "DAV: 678 only-post-allowed-to-create-new-members" to the client? With perhaps 679 a more compact name! 681 Resolution (2008-09-30): Mention the use case, define the 682 precondition, add example. 684 B.8. acl 686 Type: change 688 691 cyrus@daboo.name (2008-09-23): This brings up another question: 692 presumably the DAV:bind privilege is required on the collection for 693 the new POST ;add-member behavior to be allowed (just as it would be 694 required for PUT creating a new member). I think we therefore need a 695 statement in Security Considerations: "When a server supports WebDAV 696 ACL [RFC3744], the DAV:bind privilege is required to be granted on 697 the collection resource in which the new member resource is being 698 created. If this privilege is denied or not present, the POST 699 request MUST fail." 701 Resolution (2008-09-25): Add "relation to ACL" section; required DAV: 702 bind privilege on associated WebDAV collection. 704 B.9. member-uri-content 706 In Section 8: 708 Type: change 710 713 cyrus@daboo.name (2008-09-22): Security consideration: "Servers MUST 714 NOT derive the member path segment from the data being stored in the 715 resource". This is important because you don't want server's leaking 716 information in the URI that would not otherwise be visible (e.g. a 717 user can PROPFIND the members but cannot read the content of the 718 members - leaking content in the URI would be bad). Note this 719 impacts how the server generates the member path segment. e.g. an md5 720 hash of the data only may not be appropriate. 722 Resolution (2009-09-23): State the problem, but do not make a 723 requirement (for instance, the server could be entirely public in 724 which case this wouldn't be an issue at all). 726 Appendix C. Open issues (to be removed by RFC Editor prior to 727 publication) 729 C.1. edit 731 Type: edit 733 julian.reschke@greenbytes.de (2008-09-22): Umbrella issue for 734 editorial fixes/enhancements. 736 Index 738 A 739 Add-Member URI 6 741 C 742 Condition Names 743 p:allow-client-defined-URI (pre) 10 744 COPY method 745 Additional Preconditions 10 747 L 748 LOCK method 749 Additional Preconditions 10 751 M 752 MKCOL method 753 Additional Preconditions 10 754 MOVE method 755 Additional Preconditions 10 757 P 758 p:allow-client-defined-URI 10 759 PUT method 760 Additional Preconditions 10 762 Author's Address 764 Julian F. Reschke 765 greenbytes GmbH 766 Hafenweg 16 767 Muenster, NW 48155 768 Germany 770 Phone: +49 251 2807760 771 Email: julian.reschke@greenbytes.de 772 URI: http://greenbytes.de/tech/webdav/ 774 Full Copyright Statement 776 Copyright (C) The IETF Trust (2008). 778 This document is subject to the rights, licenses and restrictions 779 contained in BCP 78, and except as set forth therein, the authors 780 retain all their rights. 782 This document and the information contained herein are provided on an 783 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 784 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 785 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 786 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 787 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 788 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 790 Intellectual Property 792 The IETF takes no position regarding the validity or scope of any 793 Intellectual Property Rights or other rights that might be claimed to 794 pertain to the implementation or use of the technology described in 795 this document or the extent to which any license under such rights 796 might or might not be available; nor does it represent that it has 797 made any independent effort to identify any such rights. Information 798 on the procedures with respect to rights in RFC documents can be 799 found in BCP 78 and BCP 79. 801 Copies of IPR disclosures made to the IETF Secretariat and any 802 assurances of licenses to be made available, or the result of an 803 attempt made to obtain a general license or permission for the use of 804 such proprietary rights by implementers or users of this 805 specification can be obtained from the IETF on-line IPR repository at 806 http://www.ietf.org/ipr. 808 The IETF invites any interested party to bring to its attention any 809 copyrights, patents or patent applications, or other proprietary 810 rights that may cover technology that may be required to implement 811 this standard. Please address the information to the IETF at 812 ietf-ipr@ietf.org.