Internet DRAFT - draft-reschke-webdav-url-constraints
draft-reschke-webdav-url-constraints
WEBDAV Working Group J. Reschke
Internet-Draft greenbytes
Expires: May 17, 2006 November 13, 2005
Web Distributed Authoring and Versioning (WebDAV) URL constraints
draft-reschke-webdav-url-constraints-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 17, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Both WebDAV servers and clients frequently map URI-escaped characters
inside a path segment to non-ASCII characters. These mappings can
only be interoperable if there is a consensus about the appropriate
character encoding. This document specifies a default encoding that
is compatible with both the recommendations for URIs in HTML content
and the "Internationalized Resource Identifiers" (IRI) specification.
Furthermore, servers that implement a mapping to locally constrained
names frequently do not support specific names, or silently map
Reschke Expires May 17, 2006 [Page 1]
Internet-Draft WebDAV URL constraints November 2005
"similar" names to the same resource (for instance when content is
stored in a filesystem that is case-preserving, but not case-
sensitive). For these cases, discovery and error signalling features
are defined.
Editorial Note
Distribution of this document is unlimited. Please send comments to
the Distributed Authoring and Versioning (WebDAV) working group at
w3c-dist-auth@w3.org [1], which may be joined by sending a message
with subject "subscribe" to w3c-dist-auth-request@w3.org [2].
Discussions of the WEBDAV working group are archived at URL:
<http://lists.w3.org/Archives/Public/w3c-dist-auth/>.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Name to URL segment mapping . . . . . . . . . . . . . . . . . 3
5. Server Considerations . . . . . . . . . . . . . . . . . . . . 4
5.1 Overview of common mapping methods . . . . . . . . . . . . 4
5.1.1 Mapping URL segments to byte sequences . . . . . . . . 4
5.1.2 Mapping URL segments to character sequences . . . . . 5
5.1.3 Identity mapping . . . . . . . . . . . . . . . . . . . 5
5.2 Caveats . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Client Considerations . . . . . . . . . . . . . . . . . . . . 6
7. Additional Method Semantics . . . . . . . . . . . . . . . . . 6
7.1 Additional Preconditions . . . . . . . . . . . . . . . . . 6
7.1.1 DAV:name-allowed precondition . . . . . . . . . . . . 6
8. Compatibility Considerations . . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . 6
10. Internationalization Considerations . . . . . . . . . . . . 6
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
12.1 Normative References . . . . . . . . . . . . . . . . . . . 7
12.2 Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 10
Reschke Expires May 17, 2006 [Page 2]
Internet-Draft WebDAV URL constraints November 2005
1. Introduction
Both WebDAV servers and clients frequently map URI-escaped characters
(see [RFC3986]) inside a path segment to non-ASCII characters. These
mappings can only be interoperable if there is a consensus about the
appropriate character encoding. This document specifies a default
encoding that is compatible with both the recommendations for URIs in
HTML content (see [HTML], Appendix B.2.1) and the IRI specification
[RFC3987].
Furthermore, servers that implement a mapping to locally constrained
names frequently do not support specific names, or silently map
"similar" names to the same resource (for instance when content is
stored in a filesystem that is case-preserving, but not case-
sensitive). For these cases, discovery and error signalling features
are defined.
2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Terminology
The terminology used here follows that in WebDAV [RFC2518], HTTP
[RFC2616] and "Versioning Extensions to WebDAV" [RFC3253].
Definitions of the terms resource, Uniform Resource Identifier (URI),
and Uniform Resource Locator (URL) are provided in [RFC3986].
This document uses the terms "precondition" and "postcondition" as
defined in [RFC3253]. Servers SHOULD report pre-/postcondition
failures as described in section 1.6 of this document.
4. Name to URL segment mapping
In proposing a common mapping, the following requirements were taken
into account:
R1 For URL characters inside the US-ASCII range (0..127), the mapping
should be the identity mapping.
R2 The mapping should provide support for all characters defined in
the Unicode character set.
The only widely-deployed character encoding fulfilling these
requirements is the UTF-8 character decoding, defined in [RFC3629].
Consequently, it's also the encoding recommended for URLs in HTML
Reschke Expires May 17, 2006 [Page 3]
Internet-Draft WebDAV URL constraints November 2005
content ([HTML], Appendix B.2.1) and for IRIs ([RFC3987]).
Therefore, clients and servers SHOULD use the UTF-8 character
encoding to map non-ASCII characters to/from character sequences in
URL segments.
5. Server Considerations
When mapping HTTP URL segments (see [RFC3986], section 3.3) to local
storage, the server's behaviour usually depends on the API used to
access that storage. In practice, two styles are widely deployed:
binary and character-based. The sections below discuss the
implications of each and also describe an "identity" mapping.
5.1 Overview of common mapping methods
5.1.1 Mapping URL segments to byte sequences
A typical scenario for this case is when the server does a direct
mapping between URLs and objects in a filesystem, and the filesystem
uses filenames based on byte sequences. This is the case for typical
Unix filesystem implementations.
In this case, mapping between URL segments and local names is
straightforward:
o To map from URL segments, just apply URL unescaping to obtain a
byte sequence (see [RFC3986], section 2.1)
o To map to URL segments, just apply URL escaping to obtain a
sequence of characters suitable for use in a URL segment
The advantage of this simple mapping is that it faithfully stores
whatever the original URL contained. On the other hand, this is a
binary encoding, and programs that display filenames usually have to
map the byte sequence to a character sequence for display. Unless
both character encodings match, the results will be either inaccurate
(incorrect characters) or the display function will break completely
(for instance when an attempt is made to UTF-8-decode a byte stream
that was originally encoded using an incompatible encoding such as
ISO-8859-1).
Things get even more complicated when there is no single character
encoding being used on the server. For instance, in a Unix system
multiple users may use different character encodings for filenames.
However, the filesystem does not preserve information about what
character encoding the filename was encoded with; thus, depending on
their "locale" settings, different users will see different names for
Reschke Expires May 17, 2006 [Page 4]
Internet-Draft WebDAV URL constraints November 2005
the same filesystem object.
5.1.2 Mapping URL segments to character sequences
This scenario is similar to the one discussed in the previous section
(5.1.1). For instance it occurs when objects are stored locally in a
way that allows Unicode characters in names, such as filenames in the
Windows filesystem.
However, in addition to the mapping to byte sequences, an additional
mapping to a character sequence is required. As discussed in
Section 4, this mapping should use the UTF-8 character encoding
([RFC3629]). Thus, here the mapping can be described as:
o To map from URL segments, apply URL unescaping to obtain a byte
sequence (see [RFC3986], section 2.1), then UTF-8-decode to a
sequence of characters.
o To map to URL segments, UTF-8-encode the character sequence to a
sequence of bytes, then apply URL escaping to obtain a sequence of
characters suitable for use in a URL segment
5.1.3 Identity mapping
Finally, it's also possible to simply store the URL segments
character by character, in which case no special mapping
considerations apply. Note that this approach may be inefficient in
case the names contain many URL-escaped sequences (such as when asian
characters have been encoded using UTF-8).
5.2 Caveats
The non-trivial mappings have the common drawback that certain sets
of legal HTTP URLs can not be mapped to local names (and therefore
usually need to be rejected). For the byte sequence mapping
described in Section 5.1.1, this will usually be just the null
character.
However, when using the character mapping described in Section 5.1.2,
whole Unicode character ranges may either be impossible to represent
(such as when the underlying filesystem does only support a Unicode
subset), or explicitly disallowed (such as non-normalized character
sequences, see [CNORM], section 3.2).
In cases like these, servers SHOULD reject operations that attempt to
create those non-mappable URLs. Appropriate precondition names are
defined in Section 7.1.
Reschke Expires May 17, 2006 [Page 5]
Internet-Draft WebDAV URL constraints November 2005
6. Client Considerations
In general, the mappings discussed in Section 5.1.2 apply to clients
as well. Whether a client maps segments to byte or character
sequences usually depends on the platform it runs on, and what system
layer it uses. For instance, a filesystem driver for a Unix system
usually will have to translate to byte sequences (because that's how
many Unix system internally represent filenames).
However, if the client needs to do any mapping it all, there may be
sitations where parts of a URL segment can't be mapped to what the
client needs internally. In cases like these, it is recommended that
the client signals the problem, and provides a way to repair the
problem (such as renaming the resource).
7. Additional Method Semantics
7.1 Additional Preconditions
7.1.1 DAV:name-allowed precondition
The name specified by the HTTP request as path segment is available
for use as a new binding name (see [draft-ietf-webdav-bind], section
4 and 6).
8. Compatibility Considerations
Servers that use a non-identity mapping may not be able to create new
resources with the URLs specified by the client (such as in an MKCOL
or a PUT request).
Clients that use a non-identity mapping may not be able to handle all
URLs returned by a server (such as a result of a PROPFIND request).
9. Security Considerations
All of the security considerations of HTTP/1.1 and the WebDAV
Distributed Authoring Protocol specification also apply to this
protocol specification.
_TBD: add notes about the inherent security risks when a backend
storage maps multiple notations to the same physical object (file),
think uppercase/lowercase, trailing blanks/dots, resolution of
relative paths ("./", "../")._
10. Internationalization Considerations
All internationalization considerations mentioned in [RFC2518] also
Reschke Expires May 17, 2006 [Page 6]
Internet-Draft WebDAV URL constraints November 2005
apply to this document.
11. IANA Considerations
There are no IANA Considerations.
12. References
12.1 Normative References
[HTML] Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01
Specification", W3C REC REC-html401-19991224,
December 1999,
<http://www.w3.org/TR/1999/REC-html401-19991224>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.
Jensen, "HTTP Extensions for Distributed Authoring --
WEBDAV", RFC 2518, February 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J.
Whitehead, "Versioning Extensions to WebDAV", RFC 3253,
March 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629, STD 63, November 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
12.2 Informative References
[CNORM] Duerst, M., Yergau, F., Ishida, R., Wolf, M., Texin, T.,
and A. Phillips, "Character Model for the World Wide Web
1.0: Normalization", W3C WD-charmod-norm-20040225,
February 2004,
<http://www.w3.org/TR/2004/WD-charmod-norm-20040225>.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005.
Reschke Expires May 17, 2006 [Page 7]
Internet-Draft WebDAV URL constraints November 2005
[draft-ietf-webdav-bind]
Clemm, G., Crawford, J., Reschke, J., and J. Whitehead,
"Binding Extensions to Web Distributed Authoring and
Versioning (WebDAV)", draft-ietf-webdav-bind-12 (work in
progress), July 2005, <http://greenbytes.de/tech/webdav/
draft-ietf-webdav-bind-12.html>.
URIs
[1] <mailto:w3c-dist-auth@w3.org>
[2] <mailto:w3c-dist-auth-request@w3.org?subject=subscribe>
Author's Address
Julian F. Reschke
greenbytes GmbH
Hafenweg 16
Muenster, NW 48155
Germany
Phone: +49 251 2807760
Fax: +49 251 2807761
Email: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/
Reschke Expires May 17, 2006 [Page 8]
Internet-Draft WebDAV URL constraints November 2005
Index
C
Condition Names
DAV:name-allowed (pre) 6
D
DAV:name-allowed precondition 6
Reschke Expires May 17, 2006 [Page 9]
Internet-Draft WebDAV URL constraints November 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Reschke Expires May 17, 2006 [Page 10]