idnits 2.17.1 draft-reschke-webdav-property-datatypes-09.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 591. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 575. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 581. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (April 28, 2005) is 6900 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 2518 (Obsoleted by RFC 4918) -- Possible downref: Non-RFC (?) normative reference: ref. 'XS1' -- Possible downref: Non-RFC (?) normative reference: ref. 'XS2' Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 9 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 Expires: October 30, 2005 April 28, 2005 6 Datatypes for WebDAV properties 7 draft-reschke-webdav-property-datatypes-09 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on October 30, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This specification extends the Web Distributed Authoring Protocol 41 (WebDAV) to support datatyping. Protocol elements are defined to let 42 clients and servers specify the datatype, and to instruct the WebDAV 43 method PROPFIND to return datatype information. 45 Editorial Note (To be removed by RFC Editor before publication) 47 Please send comments to the Distributed Authoring and Versioning 48 (WebDAV) working group at , which may be 49 joined by sending a message with subject "subscribe" to 50 . Discussions of the WEBDAV 51 working group are archived at 52 . 54 Note that although discussion takes place on the WebDAV working 55 group's mailing list, this is not a working group document. 57 XML versions, latest edits and the issues list for this document are 58 available from . 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4 65 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. Changes for PROPPATCH method . . . . . . . . . . . . . . . . 5 67 4.1 Example for successful PROPPATCH . . . . . . . . . . . . . 6 68 4.2 Example for failed PROPPATCH . . . . . . . . . . . . . . . 7 69 4.3 Example for successful PROPPATCH where type information 70 was not preserved . . . . . . . . . . . . . . . . . . . . 8 71 5. Changes for PROPFIND method . . . . . . . . . . . . . . . . 9 72 5.1 Example for PROPFIND/prop . . . . . . . . . . . . . . . . 10 73 6. Changes for other methods . . . . . . . . . . . . . . . . . 11 74 7. Compatibility Considerations . . . . . . . . . . . . . . . . 11 75 8. Internationalization Considerations . . . . . . . . . . . . 11 76 9. Security Considerations . . . . . . . . . . . . . . . . . . 11 77 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 78 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 79 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 12.1 Normative References . . . . . . . . . . . . . . . . . . 12 81 12.2 Informative References . . . . . . . . . . . . . . . . . 12 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . 13 83 A. Change Log (to be removed by RFC Editor before 84 publication) . . . . . . . . . . . . . . . . . . . . . . . . 13 85 A.1 Since 'draft-reschke-webdav-property-datatypes-00' . . . . 13 86 A.2 Since 'draft-reschke-webdav-property-datatypes-01' . . . . 13 87 A.3 Since 'draft-reschke-webdav-property-datatypes-02' . . . . 13 88 A.4 Since 'draft-reschke-webdav-property-datatypes-03' . . . . 13 89 A.5 Since 'draft-reschke-webdav-property-datatypes-04' . . . . 13 90 A.6 Since 'draft-reschke-webdav-property-datatypes-05' . . . . 13 91 A.7 Since 'draft-reschke-webdav-property-datatypes-06' . . . . 14 92 A.8 Since 'draft-reschke-webdav-property-datatypes-07' . . . . 14 93 A.9 Since 'draft-reschke-webdav-property-datatypes-08' . . . . 14 94 B. Open issues (to be removed by RFC Editor prior to 95 publication) . . . . . . . . . . . . . . . . . . . . . . . . 14 96 B.1 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 97 Intellectual Property and Copyright Statements . . . . . . . 15 99 1. Introduction 101 This specification builds on the infrastructure provided by the 102 WebDAV Distributed Authoring Protocol, adding support for data-typed 103 properties. 105 Although servers must support XML content in property values, it may 106 be desirable to persist values as scalar values when possible, and to 107 expose the data's type when the property value is returned to the 108 client. The client is free to ignore this information, but it may be 109 able to take advantage of it when modifying a property. 111 On the other hand, when setting new properties, it can be desirable 112 to pass data type information along with the value. A server can 113 take advantage of this information to optimize storage and to perform 114 additional parsing (for instance of dates). Servers that support 115 searching can also take advantage of known data types when doing 116 comparisons and sorting. 118 The following potential datatyping related features were deliberately 119 considered out of scope: 121 o getting "schema" information for classes of resources (set of 122 "required" properties, their types, display information), 124 o definition of a set of mandatory property types, 126 o discovery of supported property types, 128 o extensions to PROPPATCH that would allow updates to parts of a 129 (structured) property. 131 2. Notational Conventions 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 The term "property element" refers to the XML element that identifies 138 a particular property, for instance 140 142 The term "prop element" is used for the WebDAV "prop" element as 143 defined in section 12.11 of [RFC2518]. 145 The XML representation of schema components uses a vocabulary 146 identified by the namespace name "http://www.w3.org/2001/XMLSchema". 147 For brevity, the text and examples in this specification use the 148 prefix "xs:" to stand for this namespace; in practice, any prefix can 149 be used. "XML Schema: Structures" ([XS1]) also defines several 150 attributes for direct use in any XML documents. These attributes are 151 in a different namespace named 152 "http://www.w3.org/2001/XMLSchema-instance". For brevity, the text 153 and examples in this specification use the prefix "xsi:" to stand for 154 this latter namespace; in practice, any prefix can be used. 156 3. Overview 158 Although WebDAV property types can be anything that can be marshaled 159 as content of an XML element, in many cases they actually are simple 160 types like integers, booleans or dates. "XML Schema Part 2: 161 Datatypes" [XS2] defines a set of simple types which can be used as a 162 basis for supplying type information to attributes. 164 Data type information is represented using the attribute "type" from 165 the XML Schema namespace "http://www.w3.org/2001/XMLSchema-instance". 166 In XML Schema, data types are qualified names, and the XML Schema 167 recommendation defines a set of built-in datatypes (section 3 of 168 [XS2]), defined in the namespace "http://www.w3.org/2001/XMLSchema". 170 To avoid unnecessary verbosity, data type information should only be 171 supplied if it adds usable information to the protocol. In 172 particular, type information is not required for live properties 173 defined in WebDAV [RFC2518] and for properties of type "xs:string". 175 A server may implement any combination of datatypes, both from the 176 XML Schema recommendation and possibly from other namespaces. 178 Note that a particular property can be typed for a number of reasons: 180 o The property is a live property with server-defined semantics and 181 value space. 183 o The property may have been set using a non-WebDAV protocol that 184 the server understands in addition to WebDAV. 186 o The type may have been specified in an extended PROPPATCH method 187 as defined in Section 4. 189 4. Changes for PROPPATCH method 191 If the property element has an XML attribute named "xsi:type", the 192 server may use this information to select an optimized representation 193 for storing the property value. For instance, by specifying a type 194 as "xs:boolean", the client declares the property value to be of type 195 boolean (as defined in [XS2]). The server may choose any suitable 196 internal format for persisting this property, and in particular is 197 allowed to fail the request if the format given does not fit the 198 format defined for this type. 200 The server should indicate successful detection and parsing of the 201 typed value by setting the xsi:type attribute on the property element 202 in the response body (this implies that it should return a 203 MULTISTATUS status code and a response body). 205 4.1 Example for successful PROPPATCH 207 >>Request 209 PROPPATCH /bar.html HTTP/1.1 210 Host: example.org 211 Content-Type: text/xml; charset="utf-8" 212 Content-Length: xxxx 214 215 219 220 221 false 222 223 224 225 >>Response 227 HTTP/1.1 207 Multi-Status 228 Content-Type: text/xml; charset="utf-8" 229 Content-Length: xxxx 231 232 236 237 http://example.org/bar.html 238 239 240 HTTP/1.1 200 OK 241 242 243 245 In this cases, the xsi:type attribute on the element "Z:released" 246 indicates that the server indeed has understood the submitted data 247 type information. 249 4.2 Example for failed PROPPATCH 251 >>Request 253 PROPPATCH /bar.html HTTP/1.1 254 Host: example.org 255 Content-Type: text/xml; charset="utf-8" 256 Content-Length: xxxx 258 259 263 264 265 t 266 267 268 269 >>Response 271 HTTP/1.1 207 Multi-Status 272 Content-Type: text/xml; charset="utf-8" 273 Content-Length: xxxx 275 276 278 279 http://example.org/bar.html 280 281 282 HTTP/1.1 422 Unprocessable Entity 283 284 Does not parse as xs:boolean 285 286 287 288 290 In this case the request failed because the supplied value "t" is not 291 a valid representation for a boolean value. 293 Note that similar error conditions can occur in the standard WebDAV 294 protocol even though no data type was specified: for instance, when a 295 client tries to set a live property for which only a certain value 296 space is allowed. 298 4.3 Example for successful PROPPATCH where type information was not 299 preserved 301 >>Request 303 PROPPATCH /bar.html HTTP/1.1 304 Host: example.org 305 Content-Type: text/xml; charset="utf-8" 306 Content-Length: xxxx 308 309 312 313 314 t 315 316 317 319 >>Response 321 HTTP/1.1 207 Multi-Status 322 Content-Type: text/xml; charset="utf-8" 323 Content-Length: xxxx 325 326 329 330 http://example.org/bar.html 331 332 333 HTTP/1.1 200 OK 334 335 336 338 In this case the request succeeded, but the server did not know how 339 to handle the data type "Z:custom". Therefore no data type 340 information was returned in the response body. 342 5. Changes for PROPFIND method 344 PROPFIND is extended to return the data type information for 345 properties by adding "xsi:type" attributes to the property elements 346 unless one of the following conditions is met: 348 o The data type MUST be different from "xs:string" (because this can 349 be considered the default data type). 351 o The property's data type MUST NOT be defined in [RFC2518] (because 352 these types are already well-defined). 354 5.1 Example for PROPFIND/prop 356 >>Request 358 PROPFIND /bar.html HTTP/1.1 359 Host: example.org 360 Content-Type: text/xml; charset="utf-8" 361 Content-Length: xxxx 363 364 366 367 368 369 370 372 >>Response 374 HTTP/1.1 207 Multi-Status 375 Content-Type: text/xml; charset="utf-8" 376 Content-Length: xxxx 378 379 383 384 http://example.org/bar.html 385 386 387 text/html 388 1 389 390 HTTP/1.1 200 OK 391 392 393 394 This example shows that the property value "true" is returned with 395 the correct data type information, and that the server chose one of 396 the two possible representations defined in XML Schema. It also 397 shows that data type information is not returned for 398 "D:getcontenttype", as this property's data type is already defined 399 in [RFC2518]. 401 6. Changes for other methods 403 Servers that support other methods using the DAV:multistatus response 404 format (such as the REPORT method defined in [RFC3253], section 3.6) 405 SHOULD apply the same extensions as defined in Section 5. 407 7. Compatibility Considerations 409 This part of this specification does not introduce any new protocol 410 elements, nor does it change the informal WebDAV DTD. It merely 411 specifies additional server semantics for the case where clients 412 submit additional data type information in an attribute on the 413 property element (previously undefined), and adds an additional 414 attribute on property elements upon PROPFIND. 416 Clients not aware of datatype handling should not supply the "xsi: 417 type" attribute on property elements (after all, this attribute 418 belongs to the XML Schema-Instance namespace which has been defined 419 for exactly this purpose). Old clients should also ignore additional 420 attributes on property elements returned by PROPFIND (and similar 421 methods), although the WebDAV specification only defines this 422 behaviour for unknown elements (and is silent about unknown 423 attributes). 425 Servers not aware of datatype handling either drop the "xsi:type" 426 attribute, or persist it along with the property value. However, 427 they will never indicate successful parsing of the data type by 428 returning back the type in the response to PROPPATCH. Thus, clients 429 can supply type information without having to poll for server support 430 in advance. 432 8. Internationalization Considerations 434 This proposal builds on [RFC2518], and inherits its 435 internationalizability. 437 9. Security Considerations 439 This protocol extension does not introduce any new security 440 implications beyond those documented for the base protocol (see 441 [RFC2518], Section 17). 443 10. IANA Considerations 445 This proposal does not introduce any new IANA considerations, since 446 it does not specify any new namespaces (in the general sense), but 447 merely uses existing ones. 449 11. Acknowledgements 451 This draft has benefited from thoughtful discussion by Lisa 452 Dusseault, Stefan Eissing, Eric Sedlar and Kevin Wiggen. 454 12. References 456 12.1 Normative References 458 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 459 Requirement Levels", BCP 14, RFC 2119, March 1997. 461 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. 462 Jensen, "HTTP Extensions for Distributed Authoring -- 463 WEBDAV", RFC 2518, February 1999. 465 [XS1] Thompson, H., Beech, D., Maloney, M., Mendelsohn, N., and 466 World Wide Web Consortium, "XML Schema Part 1: 467 Structures", W3C REC-xmlschema-1-20010502, May 2001, 468 . 470 [XS2] Biron, P., Malhotra, A., and World Wide Web Consortium, 471 "XML Schema Part 2: Datatypes Second Edition", W3C REC- 472 xmlschema-2-20041028, October 2004, 473 . 475 12.2 Informative References 477 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. 478 Whitehead, "Versioning Extensions to WebDAV", RFC 3253, 479 March 2002. 481 Author's Address 483 Julian F. Reschke 484 greenbytes GmbH 485 Salzmannstrasse 152 486 Muenster, NW 48159 487 Germany 489 Phone: +49 251 2807760 490 Fax: +49 251 2807761 491 Email: julian.reschke@greenbytes.de 492 URI: http://greenbytes.de/tech/webdav/ 494 Appendix A. Change Log (to be removed by RFC Editor before publication) 496 A.1 Since 'draft-reschke-webdav-property-datatypes-00' 498 Editorial fixes. Changed examples to explicitly use utf-8 encoding 499 for HTTP content type and XML encoding. Added example for 500 marshalling array-typed properties. 502 A.2 Since 'draft-reschke-webdav-property-datatypes-01' 504 Fix width of artwork for IETF compliance. "Non-normative references" 505 -> "Informative references". 507 A.3 Since 'draft-reschke-webdav-property-datatypes-02' 509 Added marshalling for property flags such as "hidden" and 510 "protected". Moved array marshalling example into back section. 511 Added rational and description for pf:property-displayname-set. 512 Added acknowledgements section. 514 A.4 Since 'draft-reschke-webdav-property-datatypes-03' 516 Replaced domain names in examples according to RFC2606: "www.foo.com" 517 by "example.org", "www.example.com" by "ns.example.org/standards/ 518 z39.50/standards/z39.50" and "www.w3.com/standards/z39.50" by 519 "ns.example.org/standards/z39.50". 521 A.5 Since 'draft-reschke-webdav-property-datatypes-04' 523 Remove superfluous IP and copyright sections. Moved "Introduction" 524 section to front. 526 A.6 Since 'draft-reschke-webdav-property-datatypes-05' 528 Added proposal for DAV:basicsearch operators for array-typed 529 properties. Update all references. 531 A.7 Since 'draft-reschke-webdav-property-datatypes-06' 533 Reformat abstract. Remove property flags, displayname support and 534 DASL extensions. 536 A.8 Since 'draft-reschke-webdav-property-datatypes-07' 538 Rewrite Editorial Note. Get rid of unnecessary sub section titles 539 after removal of property flags and displayname support (no change 540 tracking). Some typos fixed. Add and resolve issues "other-method- 541 semantics", "1_clarify_scope", "7_discovery" and 542 "a_remove_array_example". Removed unused reference to XML spec (no 543 change tracking). 545 A.9 Since 'draft-reschke-webdav-property-datatypes-08' 547 Update XS2 reference. Add "Security Considerations" section. 549 Appendix B. Open issues (to be removed by RFC Editor prior to 550 publication) 552 B.1 edit 554 Type: edit 556 julian.reschke@greenbytes.de (2004-07-08): Umbrella issue for 557 editorial fixes/enhancements. 559 Intellectual Property Statement 561 The IETF takes no position regarding the validity or scope of any 562 Intellectual Property Rights or other rights that might be claimed to 563 pertain to the implementation or use of the technology described in 564 this document or the extent to which any license under such rights 565 might or might not be available; nor does it represent that it has 566 made any independent effort to identify any such rights. Information 567 on the procedures with respect to rights in RFC documents can be 568 found in BCP 78 and BCP 79. 570 Copies of IPR disclosures made to the IETF Secretariat and any 571 assurances of licenses to be made available, or the result of an 572 attempt made to obtain a general license or permission for the use of 573 such proprietary rights by implementers or users of this 574 specification can be obtained from the IETF on-line IPR repository at 575 http://www.ietf.org/ipr. 577 The IETF invites any interested party to bring to its attention any 578 copyrights, patents or patent applications, or other proprietary 579 rights that may cover technology that may be required to implement 580 this standard. Please address the information to the IETF at 581 ietf-ipr@ietf.org. 583 Disclaimer of Validity 585 This document and the information contained herein are provided on an 586 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 587 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 588 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 589 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 590 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 591 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 593 Copyright Statement 595 Copyright (C) The Internet Society (2005). This document is subject 596 to the rights, licenses and restrictions contained in BCP 78, and 597 except as set forth therein, the authors retain all their rights. 599 Acknowledgment 601 Funding for the RFC Editor function is currently provided by the 602 Internet Society.