idnits 2.17.1 draft-reschke-webdav-url-constraints-00.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 398. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 375. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 382. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 388. ** 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (November 13, 2005) is 6739 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'HTML' ** Obsolete normative reference: RFC 2518 (Obsoleted by RFC 4918) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 WEBDAV Working Group J. Reschke 3 Internet-Draft greenbytes 4 Expires: May 17, 2006 November 13, 2005 6 Web Distributed Authoring and Versioning (WebDAV) URL constraints 7 draft-reschke-webdav-url-constraints-00 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 May 17, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 Both WebDAV servers and clients frequently map URI-escaped characters 41 inside a path segment to non-ASCII characters. These mappings can 42 only be interoperable if there is a consensus about the appropriate 43 character encoding. This document specifies a default encoding that 44 is compatible with both the recommendations for URIs in HTML content 45 and the "Internationalized Resource Identifiers" (IRI) specification. 47 Furthermore, servers that implement a mapping to locally constrained 48 names frequently do not support specific names, or silently map 49 "similar" names to the same resource (for instance when content is 50 stored in a filesystem that is case-preserving, but not case- 51 sensitive). For these cases, discovery and error signalling features 52 are defined. 54 Editorial Note 56 Distribution of this document is unlimited. Please send comments to 57 the Distributed Authoring and Versioning (WebDAV) working group at 58 w3c-dist-auth@w3.org [1], which may be joined by sending a message 59 with subject "subscribe" to w3c-dist-auth-request@w3.org [2]. 61 Discussions of the WEBDAV working group are archived at URL: 62 . 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 68 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 4. Name to URL segment mapping . . . . . . . . . . . . . . . . . 3 70 5. Server Considerations . . . . . . . . . . . . . . . . . . . . 4 71 5.1 Overview of common mapping methods . . . . . . . . . . . . 4 72 5.1.1 Mapping URL segments to byte sequences . . . . . . . . 4 73 5.1.2 Mapping URL segments to character sequences . . . . . 5 74 5.1.3 Identity mapping . . . . . . . . . . . . . . . . . . . 5 75 5.2 Caveats . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 6. Client Considerations . . . . . . . . . . . . . . . . . . . . 6 77 7. Additional Method Semantics . . . . . . . . . . . . . . . . . 6 78 7.1 Additional Preconditions . . . . . . . . . . . . . . . . . 6 79 7.1.1 DAV:name-allowed precondition . . . . . . . . . . . . 6 80 8. Compatibility Considerations . . . . . . . . . . . . . . . . . 6 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 82 10. Internationalization Considerations . . . . . . . . . . . . 6 83 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 85 12.1 Normative References . . . . . . . . . . . . . . . . . . . 7 86 12.2 Informative References . . . . . . . . . . . . . . . . . . 7 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 88 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 89 Intellectual Property and Copyright Statements . . . . . . . . 10 91 1. Introduction 93 Both WebDAV servers and clients frequently map URI-escaped characters 94 (see [RFC3986]) inside a path segment to non-ASCII characters. These 95 mappings can only be interoperable if there is a consensus about the 96 appropriate character encoding. This document specifies a default 97 encoding that is compatible with both the recommendations for URIs in 98 HTML content (see [HTML], Appendix B.2.1) and the IRI specification 99 [RFC3987]. 101 Furthermore, servers that implement a mapping to locally constrained 102 names frequently do not support specific names, or silently map 103 "similar" names to the same resource (for instance when content is 104 stored in a filesystem that is case-preserving, but not case- 105 sensitive). For these cases, discovery and error signalling features 106 are defined. 108 2. Notational Conventions 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 3. Terminology 116 The terminology used here follows that in WebDAV [RFC2518], HTTP 117 [RFC2616] and "Versioning Extensions to WebDAV" [RFC3253]. 118 Definitions of the terms resource, Uniform Resource Identifier (URI), 119 and Uniform Resource Locator (URL) are provided in [RFC3986]. 121 This document uses the terms "precondition" and "postcondition" as 122 defined in [RFC3253]. Servers SHOULD report pre-/postcondition 123 failures as described in section 1.6 of this document. 125 4. Name to URL segment mapping 127 In proposing a common mapping, the following requirements were taken 128 into account: 130 R1 For URL characters inside the US-ASCII range (0..127), the mapping 131 should be the identity mapping. 133 R2 The mapping should provide support for all characters defined in 134 the Unicode character set. 136 The only widely-deployed character encoding fulfilling these 137 requirements is the UTF-8 character decoding, defined in [RFC3629]. 138 Consequently, it's also the encoding recommended for URLs in HTML 139 content ([HTML], Appendix B.2.1) and for IRIs ([RFC3987]). 141 Therefore, clients and servers SHOULD use the UTF-8 character 142 encoding to map non-ASCII characters to/from character sequences in 143 URL segments. 145 5. Server Considerations 147 When mapping HTTP URL segments (see [RFC3986], section 3.3) to local 148 storage, the server's behaviour usually depends on the API used to 149 access that storage. In practice, two styles are widely deployed: 150 binary and character-based. The sections below discuss the 151 implications of each and also describe an "identity" mapping. 153 5.1 Overview of common mapping methods 155 5.1.1 Mapping URL segments to byte sequences 157 A typical scenario for this case is when the server does a direct 158 mapping between URLs and objects in a filesystem, and the filesystem 159 uses filenames based on byte sequences. This is the case for typical 160 Unix filesystem implementations. 162 In this case, mapping between URL segments and local names is 163 straightforward: 165 o To map from URL segments, just apply URL unescaping to obtain a 166 byte sequence (see [RFC3986], section 2.1) 168 o To map to URL segments, just apply URL escaping to obtain a 169 sequence of characters suitable for use in a URL segment 171 The advantage of this simple mapping is that it faithfully stores 172 whatever the original URL contained. On the other hand, this is a 173 binary encoding, and programs that display filenames usually have to 174 map the byte sequence to a character sequence for display. Unless 175 both character encodings match, the results will be either inaccurate 176 (incorrect characters) or the display function will break completely 177 (for instance when an attempt is made to UTF-8-decode a byte stream 178 that was originally encoded using an incompatible encoding such as 179 ISO-8859-1). 181 Things get even more complicated when there is no single character 182 encoding being used on the server. For instance, in a Unix system 183 multiple users may use different character encodings for filenames. 184 However, the filesystem does not preserve information about what 185 character encoding the filename was encoded with; thus, depending on 186 their "locale" settings, different users will see different names for 187 the same filesystem object. 189 5.1.2 Mapping URL segments to character sequences 191 This scenario is similar to the one discussed in the previous section 192 (5.1.1). For instance it occurs when objects are stored locally in a 193 way that allows Unicode characters in names, such as filenames in the 194 Windows filesystem. 196 However, in addition to the mapping to byte sequences, an additional 197 mapping to a character sequence is required. As discussed in 198 Section 4, this mapping should use the UTF-8 character encoding 199 ([RFC3629]). Thus, here the mapping can be described as: 201 o To map from URL segments, apply URL unescaping to obtain a byte 202 sequence (see [RFC3986], section 2.1), then UTF-8-decode to a 203 sequence of characters. 205 o To map to URL segments, UTF-8-encode the character sequence to a 206 sequence of bytes, then apply URL escaping to obtain a sequence of 207 characters suitable for use in a URL segment 209 5.1.3 Identity mapping 211 Finally, it's also possible to simply store the URL segments 212 character by character, in which case no special mapping 213 considerations apply. Note that this approach may be inefficient in 214 case the names contain many URL-escaped sequences (such as when asian 215 characters have been encoded using UTF-8). 217 5.2 Caveats 219 The non-trivial mappings have the common drawback that certain sets 220 of legal HTTP URLs can not be mapped to local names (and therefore 221 usually need to be rejected). For the byte sequence mapping 222 described in Section 5.1.1, this will usually be just the null 223 character. 225 However, when using the character mapping described in Section 5.1.2, 226 whole Unicode character ranges may either be impossible to represent 227 (such as when the underlying filesystem does only support a Unicode 228 subset), or explicitly disallowed (such as non-normalized character 229 sequences, see [CNORM], section 3.2). 231 In cases like these, servers SHOULD reject operations that attempt to 232 create those non-mappable URLs. Appropriate precondition names are 233 defined in Section 7.1. 235 6. Client Considerations 237 In general, the mappings discussed in Section 5.1.2 apply to clients 238 as well. Whether a client maps segments to byte or character 239 sequences usually depends on the platform it runs on, and what system 240 layer it uses. For instance, a filesystem driver for a Unix system 241 usually will have to translate to byte sequences (because that's how 242 many Unix system internally represent filenames). 244 However, if the client needs to do any mapping it all, there may be 245 sitations where parts of a URL segment can't be mapped to what the 246 client needs internally. In cases like these, it is recommended that 247 the client signals the problem, and provides a way to repair the 248 problem (such as renaming the resource). 250 7. Additional Method Semantics 252 7.1 Additional Preconditions 254 7.1.1 DAV:name-allowed precondition 256 The name specified by the HTTP request as path segment is available 257 for use as a new binding name (see [draft-ietf-webdav-bind], section 258 4 and 6). 260 8. Compatibility Considerations 262 Servers that use a non-identity mapping may not be able to create new 263 resources with the URLs specified by the client (such as in an MKCOL 264 or a PUT request). 266 Clients that use a non-identity mapping may not be able to handle all 267 URLs returned by a server (such as a result of a PROPFIND request). 269 9. Security Considerations 271 All of the security considerations of HTTP/1.1 and the WebDAV 272 Distributed Authoring Protocol specification also apply to this 273 protocol specification. 275 _TBD: add notes about the inherent security risks when a backend 276 storage maps multiple notations to the same physical object (file), 277 think uppercase/lowercase, trailing blanks/dots, resolution of 278 relative paths ("./", "../")._ 280 10. Internationalization Considerations 282 All internationalization considerations mentioned in [RFC2518] also 283 apply to this document. 285 11. IANA Considerations 287 There are no IANA Considerations. 289 12. References 291 12.1 Normative References 293 [HTML] Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 294 Specification", W3C REC REC-html401-19991224, 295 December 1999, 296 . 298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 299 Requirement Levels", BCP 14, RFC 2119, March 1997. 301 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. 302 Jensen, "HTTP Extensions for Distributed Authoring -- 303 WEBDAV", RFC 2518, February 1999. 305 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 306 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 307 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 309 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. 310 Whitehead, "Versioning Extensions to WebDAV", RFC 3253, 311 March 2002. 313 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 314 10646", RFC 3629, STD 63, November 2003. 316 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 317 Resource Identifier (URI): Generic Syntax", STD 66, 318 RFC 3986, January 2005. 320 12.2 Informative References 322 [CNORM] Duerst, M., Yergau, F., Ishida, R., Wolf, M., Texin, T., 323 and A. Phillips, "Character Model for the World Wide Web 324 1.0: Normalization", W3C WD-charmod-norm-20040225, 325 February 2004, 326 . 328 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 329 Identifiers (IRIs)", RFC 3987, January 2005. 331 [draft-ietf-webdav-bind] 332 Clemm, G., Crawford, J., Reschke, J., and J. Whitehead, 333 "Binding Extensions to Web Distributed Authoring and 334 Versioning (WebDAV)", draft-ietf-webdav-bind-12 (work in 335 progress), July 2005, . 338 URIs 340 [1] 342 [2] 344 Author's Address 346 Julian F. Reschke 347 greenbytes GmbH 348 Hafenweg 16 349 Muenster, NW 48155 350 Germany 352 Phone: +49 251 2807760 353 Fax: +49 251 2807761 354 Email: julian.reschke@greenbytes.de 355 URI: http://greenbytes.de/tech/webdav/ 357 Index 359 C 360 Condition Names 361 DAV:name-allowed (pre) 6 363 D 364 DAV:name-allowed precondition 6 366 Intellectual Property Statement 368 The IETF takes no position regarding the validity or scope of any 369 Intellectual Property Rights or other rights that might be claimed to 370 pertain to the implementation or use of the technology described in 371 this document or the extent to which any license under such rights 372 might or might not be available; nor does it represent that it has 373 made any independent effort to identify any such rights. Information 374 on the procedures with respect to rights in RFC documents can be 375 found in BCP 78 and BCP 79. 377 Copies of IPR disclosures made to the IETF Secretariat and any 378 assurances of licenses to be made available, or the result of an 379 attempt made to obtain a general license or permission for the use of 380 such proprietary rights by implementers or users of this 381 specification can be obtained from the IETF on-line IPR repository at 382 http://www.ietf.org/ipr. 384 The IETF invites any interested party to bring to its attention any 385 copyrights, patents or patent applications, or other proprietary 386 rights that may cover technology that may be required to implement 387 this standard. Please address the information to the IETF at 388 ietf-ipr@ietf.org. 390 Disclaimer of Validity 392 This document and the information contained herein are provided on an 393 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 394 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 395 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 396 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 397 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 398 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 400 Copyright Statement 402 Copyright (C) The Internet Society (2005). This document is subject 403 to the rights, licenses and restrictions contained in BCP 78, and 404 except as set forth therein, the authors retain all their rights. 406 Acknowledgment 408 Funding for the RFC Editor function is currently provided by the 409 Internet Society.