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.