idnits 2.17.1
draft-ietf-webdav-acl-05.txt:
-(1122): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** The document seems to lack a 1id_guidelines paragraph about 6 months
document validity -- however, there's a paragraph with a matching
beginning. Boilerplate error?
== There is 1 instance of lines with non-ascii characters in the document.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
== The page length should not exceed 58 lines per page, but there was 30
longer pages, the longest (page 5) being 63 lines
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 2 instances of too long lines in the document, the longest one
being 1 character in excess of 72.
== There are 6 instances of lines with non-RFC2606-compliant FQDNs in the
document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== Line 556 has weird spacing: '...servers that ...'
-- 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 23, 2001) is 8403 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)
== Missing Reference: 'WEBDAV' is mentioned on line 334, but not defined
== Unused Reference: 'RFC2026' is defined on line 1407, but no explicit
reference was found in the text
-- Possible downref: Non-RFC (?) normative reference: ref. 'REC-XML'
** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
RFC 7232, RFC 7233, RFC 7234, RFC 7235)
** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615,
RFC 7616, RFC 7617)
** Obsolete normative reference: RFC 2518 (Obsoleted by RFC 4918)
** Obsolete normative reference: RFC 2368 (Obsoleted by RFC 6068)
** Obsolete normative reference: RFC 2255 (Obsoleted by RFC 4510, RFC 4516)
** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303)
** Obsolete normative reference: RFC 2279 (ref. 'UTF-8') (Obsoleted by RFC
3629)
Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 INTERNET-DRAFT Geoffrey Clemm, Rational Software
2 draft-ietf-webdav-acl-05 Anne Hopkins, Microsoft Corporation
3 Eric Sedlar, Oracle Corporation
4 Jim Whitehead, U.C. Santa Cruz
6 Expires July 21, 2001 April 23, 2001
8 WebDAV Access Control Protocol
10 Status of this Memo
12 This document is an Internet-Draft and is in full conformance with all
13 provisions of Section 10 of RFC2026.
15 Internet-Drafts are working documents of the Internet Engineering Task
16 Force (IETF), its areas, and its working groups. Note that other groups
17 may also distribute working documents as Internet-Drafts.
19 Internet-Drafts are draft documents valid for a maximum of six months
20 and may be updated, replaced, or obsoleted by other documents at any
21 time. It is inappropriate to use Internet- Drafts as reference material
22 or to cite them other than as "work in progress."
24 The list of current Internet-Drafts can be accessed at
25 http://www.ietf.org/ietf/1id-abstracts.txt
27 The list of Internet-Draft Shadow Directories can be accessed at
28 http://www.ietf.org/shadow.html.
30 Abstract
32 This document specifies a set of methods, headers, and message bodies
33 that define the WebDAV Access Control extensions to the HTTP/1.1
34 protocol. This protocol permits a client to remotely read and modify
35 access control lists that instruct a server whether to grant or deny
36 operations upon a resource (such as HTTP method invocations) by a given
37 principal.
39 This document is a product of the Web Distributed Authoring and
40 Versioning (WebDAV) working group of the Internet Engineering Task
41 Force. Comments on this draft are welcomed, and should be addressed to
42 the acl@webdav.org mailing list. Other related documents can be found at
43 http://www.webdav.org/acl/, and http://www.ics.uci.edu/pub/ietf/webdav/.
45 Table of Contents
47 1 INTRODUCTION......................................................4
48 1.1 Terms...........................................................5
49 1.2 Notational Conventions..........................................6
51 2 PRINCIPALS........................................................6
53 3 PRIVILEGES........................................................6
54 3.1 DAV:read Privilege..............................................7
55 3.2 DAV:write Privilege.............................................7
56 3.3 DAV:read-acl Privilege..........................................8
57 3.4 DAV:read-cuprivset Privilege....................................8
58 3.5 DAV:write-acl Privilege.........................................8
59 3.6 DAV:all Privilege...............................................8
61 4 PRINCIPAL PROPERTIES..............................................8
62 4.1 DAV:is-principal................................................9
63 4.2 DAV:alternate-URL...............................................9
65 5 ACCESS CONTROL PROPERTIES.........................................9
66 5.1 DAV:owner.......................................................9
67 5.2 DAV:supported-privilege-set....................................10
68 5.3 DAV:current-user-privilege-set.................................11
69 5.4 DAV:acl........................................................11
70 5.4.1 ACE Principal...............................................11
71 5.4.2 ACE Grant and Deny..........................................13
72 5.4.3 ACE Protection..............................................13
73 5.4.4 ACE Inheritance.............................................13
74 5.5 DAV:acl-semantics..............................................13
75 5.6 DAV:principal-collection-set...................................14
76 5.7 Example: PROPFIND to retrieve access control properties........14
78 6 ACL SEMANTICS....................................................17
79 6.1 ACE Combination................................................17
80 6.1.1 DAV:first-match ACE Combination.............................18
81 6.1.2 DAV:all-grant-before-any-deny ACE Combination...............18
82 6.1.3 DAV:specific-deny-overrides-grant ACE Combination...........18
83 6.2 ACE Ordering...................................................18
84 6.2.1 DAV:deny-before-grant ACE Ordering..........................18
85 6.3 Required Principals............................................18
87 7 ACCESS CONTROL AND EXISTING METHODS..............................19
88 7.1 OPTIONS........................................................19
89 7.1.1 Example - OPTIONS...........................................19
91 8 ACCESS CONTROL METHODS...........................................19
92 8.1 ACL............................................................19
93 8.1.1 ACL Preconditions...........................................20
94 8.1.2 Example: the ACL method.....................................20
95 8.1.3 Example: ACL method failure due to omission of protected ACE21
96 8.1.4 Example: ACL method failure due to inherited ACEs preceding
97 non-inherited ACEs................................................22
98 8.1.5 Example: ACL method failure due to an attempt to set grant and
99 deny in a single ACE..............................................23
101 9 INTERNATIONALIZATION CONSIDERATIONS..............................24
103 10 SECURITY CONSIDERATIONS........................................25
104 10.1 Increased Risk of Compromised Users...........................25
105 10.2 Risks of the read-acl and cuprivset Privileges................25
107 11 AUTHENTICATION.................................................26
109 12 IANA CONSIDERATIONS............................................26
111 13 INTELLECTUAL PROPERTY..........................................26
113 14 ACKNOWLEDGEMENTS...............................................26
115 15 REFERENCES.....................................................27
116 15.1 Normative References..........................................27
117 15.2 Informational References......................................28
119 16 AUTHORS' ADDRESSES.............................................28
121 17 APPENDICIES....................................................28
122 17.1 XML Document Type Definition..................................28
123 1 INTRODUCTION
125 The goal of the WebDAV access control extensions is to provide an
126 interoperable mechanism for handling discretionary access control
127 for content in WebDAV servers. WebDAV access control can be
128 implemented on content repositories with security as simple as that
129 of a UNIX file system, as well as more sophisticated models. The
130 underlying principle of access control is that who you are
131 determines how you can access a resource. The "who you are" is
132 defined by a "principal" identifier; users, client software,
133 servers, and groups of the previous have principal identifiers. The
134 "how" is determined by a single "access control list" (ACL)
135 associated with a resource. An ACL contains a set of "access
136 control entries" (ACEs), where each ACE specifies a principal and a
137 set of privileges that are either granted or denied to that
138 principal. When a principal submits an operation (such as an HTTP
139 or WebDAV method) to a resource for execution, the server evaluates
140 the ACEs in the ACL to determine if the principal has permission
141 for that operation.
143 This specification intentionally omits discussion of
144 authentication, as the HTTP protocol already has a number of
145 authentication mechanisms [RFC2617]. Some authentication mechanism
146 (such as HTTP Digest Authentication, which all WebDAV compliant
147 implementations are required to support) must be available to
148 validate the identity of a principal.
150 In the interests of timeliness, the following set of security
151 mechanisms are not addressed by this document:
153 * Access control that applies only to a particular property on a
154 resource (excepting the access control properties DAV:acl and
155 DAV:current-user-privilege-set), rather than the entire
156 resource,
158 * Role-based security (where a role can be seen as a dynamically
159 defined collection of principals),
161 * Specification of the ways an ACL on a resource is initialized,
163 * Specification of an ACL that applies globally to a method,
164 rather than to a particular resource.
166 This specification is organized as follows. Section 1.1 defines key
167 concepts used throughout the specification, and is followed by more
168 in-depth discussion of principals (Section 2), and privileges
169 (Section 3). Properties defined on principals are specified in
170 Section 4, and access control properties for content resources are
171 specified in Section 5. The semantics of access control lists are
172 described in Section 6, including sections on ACE combination
173 (Section 6.1), ACE ordering (Section 6.2), and principals required
174 to be present in an ACE (Section 6.3). Client discovery of access
175 control capability using OPTIONS is described in Section 7.1, and
176 the access control setting method, ACL, is specified in Section 8.
178 Internationalization considerations (Section 9) and security
179 considerations (Section 10) round out the specification. An
180 appendix (Section 17.1) provides an XML Document Type Definition
181 (DTD) for the XML elements defined in the specification.
183 1.1 Terms
185 This draft uses the terms defined in HTTP [RFC2616] and WebDAV
186 [RFC2518]. In addition, the following terms are defined:
188 principal
190 A "principal" is a distinct human or computational actor that
191 initiates access to network resources. In this protocol, a
192 principal is an HTTP resource that represents such an actor.
194 principal collection
196 A "principal collection" is a group of principals, and is
197 represented in this protocol by a WebDAV collection containing HTTP
198 resources that represent principals, and principal collections.
200 privilege
202 A "privilege" controls access to a particular set of HTTP
203 operations on a resource.
205 aggregate privilege
207 An "aggregate privilege" is a privilege that contains a set of
208 other privileges.
210 abstract privilege
212 The modifier "abstract", when applied to an atomic or aggregate
213 privilege, means the privilege cannot be set in an access control
214 element (ace).
216 access control list (acl)
218 An "acl" is a list of access control elements that define access
219 control to a particular resource.
221 access control element (ace)
223 An "ace" either grants or denies a particular set of (non-abstract)
224 privileges for a particular principal.
226 inherited ace
228 An "inherited ace" is an ace that is shared from the acl of another
229 resource.
231 1.2 Notational Conventions
233 The augmented BNF used by this document to describe protocol
234 elements is described in Section 2.1 of [RFC2616]. Because this
235 augmented BNF uses the basic production rules provided in Section
236 2.2 of [RFC2616], those rules apply to this document as well.
238 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
239 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
240 this document are to be interpreted as described in [RFC2119].
242 2 PRINCIPALS
244 A principal is a network resource that represents a distinct human
245 or computational actor that initiates access to network resources.
246 On many implementations, users and groups are represented as
247 principals; other types of principals are also possible. A URL of
248 any scheme MAY be used to identify a principal resource. However,
249 servers implementing this specification SHOULD expose principal
250 resources at an http(s) URL, which is a privileged scheme that
251 points to resources that have additional properties, as described
252 in Section 4. Although an implementation SHOULD support PROPFIND
253 and PROPPATCH to access and modify information about a principal,
254 it is not required to do so.
256 A principal resource may or may not be a collection. A collection
257 principal may only contain other principals (not other types of
258 resources). Servers that support aggregation of principals (e.g.
259 groups of users or other groups) MUST manifest them as collection
260 principals. The WebDAV methods for examining and maintaining
261 collections (e.g. DELETE, PROPFIND) MAY be used to maintain
262 collection principals. Membership in a collection principal is
263 recursive, so a principal in a collection principal GRPA contained
264 by collection principal GRPB is a member of both GRPA and GRPB.
265 Implementations not supporting recursive membership in principal
266 collections can return an error if the client attempts to bind
267 collection principals into other collection principals.
269 3 PRIVILEGES
271 Ability to perform a given method on a resource SHOULD be
272 controlled by one or more privileges. Authors of protocol
273 extensions that define new HTTP methods SHOULD specify which
274 privileges (by defining new privileges, or mapping to ones below)
275 are required to perform the method. A principal with no privileges
276 to a resource SHOULD be denied any HTTP access to that resource.
278 Privileges may be containers of other privileges, in which case
279 they are termed aggregate privileges. If a principal is granted or
280 denied an aggregate privilege, it is semantically equivalent to
281 granting or denying each of the aggregated privileges individually.
282 For example, an implementation may define add-member and remove-
283 member privileges that control the ability to add and remove an
284 internal member of a collection. Since these privileges control
285 the ability to update the state of a collection, these privileges
286 would be aggregated by the DAV:write privilege on a collection, and
287 granting the DAV:write privilege on a collection would also grant
288 the add-member and remove-member privileges.
290 Privileges may have the quality of being abstract, in which case
291 they cannot be set in an ACE. Aggregate and atomic privileges are
292 both capable of being abstract. Abstract privileges are useful for
293 modeling privileges that otherwise would not be exposed via the
294 protocol. Abstract privileges also provide server implementations
295 with flexibility in implementing the privileges defined in this
296 specification. For example, if a server is incapable of separating
297 the read resource capability from the read ACL capability, it can
298 still model the DAV:read and DAV:read-acl privileges defined in
299 this specification by declaring them abstract, and containing them
300 within a non-abstract aggregate privilege (say, read-all) that
301 holds DAV:read, and DAV:read-acl. In this way, it is possible to
302 set the aggregate privilege, read-all, thus coupling the setting of
303 DAV:read and DAV:read-acl, but it is not possible to set DAV:read,
304 or DAV:read-acl individually. Since aggregate privileges can be
305 abstract, it is also possible to use abstract privileges to group
306 and classify non-abstract privileges.
308 The set of privileges that apply to a particular resource may vary
309 with the DAV:resourcetype of the resource, as well as between
310 different server implementations. To promote interoperability,
311 however, WebDAV defines a set of well-known privileges (e.g.
312 DAV:read and DAV:write), which can at least be used to classify the
313 other privileges defined on a particular resource. The access
314 permissions on null and lock-null resources are solely those they
315 inherit (if any), and they are not discoverable (i.e., the ACL
316 properties specified in Section 5 are not defined on null and lock-
317 null resources). On the transition from null or lock-null to a
318 stateful resource, the initial access control list is set by the
319 server's default ACL value policy (if any).
321 3.1 DAV:read Privilege
323 The read privilege controls methods that return information about
324 the state of the resource, including the resource's properties.
325 Affected methods include GET and PROPFIND. Additionally, the read
326 privilege MAY control the OPTIONS method.
328
330 3.2 DAV:write Privilege
332 The write privilege controls methods that modify the state of the
333 resource, such as PUT and PROPPATCH. Note that state modification
334 is also controlled via locking (see section 5.3 of [WEBDAV]), so
335 effective write access requires that both write privileges and
336 write locking requirements are satisfied.
338
339 3.3 DAV:read-acl Privilege
341 The DAV:read-acl privilege controls the use of PROPFIND to retrieve
342 the DAV:acl property of the resource.
344
346 3.4 DAV:read-cuprivset Privilege
348 The DAV:read-cuprivset privilege controls the use of PROPFIND to
349 retrieve the DAV:current-user-privilege-set property of the
350 resource.
352 Clients are intended to use this property to visually indicate in
353 their UI items that are dependent on the permissions of a resource,
354 for example, by graying out resources that are not writeable.
356 This privilege is separate from DAV:read-acl because there is a
357 need to allow most users access to the privileges permitted the
358 current user (due to its use in creating the UI), while the full
359 ACL contains information that may not be appropriate for the
360 current authenticated user. As a result, the set of users who can
361 view the full ACL is expected to be much smaller than those who can
362 read the current user privilege set, and hence distinct privileges
363 are needed for each
365
367 3.5 DAV:write-acl Privilege
369 The DAV:write-acl privilege controls use of the ACL method to
370 modify the DAV:acl property of the resource.
372
374 3.6 DAV:all Privilege
376 DAV:all is an aggregate privilege that contains all privileges on
377 the resource.
379
381 4 PRINCIPAL PROPERTIES
383 Principals are manifested to clients as an HTTP resource,
384 identified by a URL. A principal MUST have a DAV:displayname
385 property. This protocol defines the following additional
386 properties for a principal. The name and value of these properties
387 SHOULD NOT be returned by PROPFIND allprop request (as defined in
388 Section 12.14.1 of [RFC2518]). In the descriptions below, a read-
389 only property is defined as a property that MUST NOT be writeable
390 using PROPPATCH.
392 4.1 DAV:is-principal
394 This is a read-only property that indicates whether this resource
395 is a principal. A resource MUST have a non-empty DAV:is-principal
396 property if and only if it is a principal resource.
398
399 PCDATA value: "true" - resource is a principal, "false" - resource
400 is not a principal (note that in cases where the "F" value might be
401 used, this specification requires the property not be present at
402 all).
404 4.2 DAV:alternate-URL
406 This read-only property, if present, contains the URL of a network
407 resource with additional descriptive information about the
408 principal. This property identifies one or more additional network
409 resources (i.e., it contains one or more URLs) that may be
410 consulted by a client to gain additional knowledge concerning a
411 principal. Two potential uses for this property are to store an
412 ldap [RFC2255] or mailto [RFC2368] scheme URL. Support for this
413 property is OPTIONAL.
415
417 5 ACCESS CONTROL PROPERTIES
419 This specification defines a number of new properties for WebDAV
420 resources. Access control properties may be retrieved just like
421 other WebDAV properties, using the PROPFIND method. Some access
422 control properties (such as DAV:owner) MAY be updated with the
423 PROPPATCH method. In the descriptions below, a read-only property
424 is defined as a property that MUST NOT be writeable using
425 PROPPATCH. Since it is expensive, for many servers, to retrieve
426 access control information, a PROPFIND allprop request (as defined
427 in Section 12.14.1 of [RFC2518]) SHOULD NOT return the names and
428 values of the properties defined in this section.
430 HTTP resources that support the WebDAV Access Control Protocol MUST
431 contain the following properties. Null, and lock-null resources
432 (described in Section 7.4 of [RFC2518]) MUST NOT contain the
433 following properties:
435 5.1 DAV:owner
437 This property identifies a particular principal as being the
438 "owner" of the resource. Since the owner of a resource often has
439 special access control capabilities (e.g., the owner frequently has
440 permanent write-ACL privilege), clients might display the resource
441 owner in their user interface.
443
444
445 An implementation MAY include a list of selected properties of that
446 principal resource. Which properties (if any) are included is
447 implementation defined, but might reasonably include properties
448 such as DAV:displayname, which is useful for the construction of
449 access control user interfaces on the client. A server might
450 support this capability if it wished to save the client the
451 additional network round-trip delay required to retrieve this
452 information using a PROPFIND request on the principal URL in the
453 href element. Servers that do not directly support PROPFIND on
454 principal resources might also support this feature, since it
455 allows them to return a server-controlled subset of the properties
456 on the principal resource.
458 An implementation MAY allow the use of PROPPATCH to update the
459 DAV:owner field. If the DAV:owner property is writeable, clients
460 MUST NOT submit the prop element; only the href element can be
461 modified by the client. The purpose of this restriction is to limit
462 the scope of effect of a PROPPATCH to just the owner property's
463 resource; setting the prop element would additionally require
464 modification to properties of the principal resource identified by
465 the href element.
467 5.2 DAV:supported-privilege-set
469 This is a read-only property that identifies the privileges defined
470 for the resource.
472
474 Each privilege appears as an XML element, where aggregate
475 privileges list as sub-elements all of the privileges that they
476 aggregate.
478
480
482 An abstract privilege of a resource MUST NOT be used in an ACE for
483 that resource. Servers MUST fail an attempt to set an abstract
484 privilege.
486
488 A description is a human-readable description of what this
489 privilege controls access to.
491
493 It is envisioned that a WebDAV ACL-aware administrative client
494 would list the supported privileges in a dialog box, and allow the
495 user to choose non-abstract privileges to apply in an ACE. The
496 privileges tree is useful programmatically to map well-known
497 privileges (defined by WebDAV or other standards groups) into
498 privileges that are supported by any particular server
499 implementation. The privilege tree also serves to hide complexity
500 in implementations allowing large number of privileges to be
501 defined by displaying aggregates to the user.
503 5.3 DAV:current-user-privilege-set
505 DAV:current-user-privilege-set is a read-only property containing
506 the exact set of privileges (as computed by the server) granted to
507 the currently authenticated HTTP user. Aggregate privileges and
508 their contained privileges are listed. A user-agent can use the
509 value of this property to adjust its user interface to make actions
510 inaccessible (e.g., by graying out a menu item or button) for which
511 the current principal does not have permission. This is
512 particularly useful for an access control user interface, which can
513 be constructed without knowing the ACE combining semantics of the
514 server. This property is also useful for determining what
515 operations the current principal can perform, without having to
516 actually execute an operation.
518
519
521 If the current user is granted a specific privilege, that privilege
522 must belong to the set of privileges that may be set on this
523 resource. Therefore, each element in the DAV:current-user-
524 privilege-set property MUST identify a non-abstract privilege from
525 the DAV:supported-privilege-set property.
527 5.4 DAV:acl
529 This is a read-only property that specifies the list of access
530 control entries (ACEs), which define what principals are to get
531 what privileges for this resource.
533
535 Each DAV:ace element specifies the set of privileges to be either
536 granted or denied to a single principal. If the DAV:acl property
537 is empty, no principal is granted any privilege.
539
541 5.4.1 ACE Principal
543 The DAV:principal element identifies the principal to which this
544 ACE applies.
546
549 The current user matches DAV:href only if that user is
550 authenticated as being (or being a member of) the principal
551 identified by the URL contained by that DAV:href. An implementation
552 MAY include a DAV:prop element after the DAV:href element,
553 containing a list of selected properties of that principal
554 resource. Which properties (if any) are included in the DAV:prop
555 element is implementation defined. The DAV:prop element can be used
556 by servers that do not support PROPFIND requests on principal
557 resources to return principal-related information (such as the
558 value of the DAV:displayname property) that a client would find
559 useful in the creation of an access control user interface. A
560 server might also support this capability if it wished to save the
561 client the additional network round-trip delays required to
562 retrieve this information via a series of PROPFIND requests on each
563 principal URL in the ACL. In the worst case, this is one additional
564 PROPFIND per ACE.
566
568 The current user always matches DAV:all.
570
572 The current user matches DAV:authenticated only if authenticated.
574
576 The current user matches DAV:unauthenticated only if not
577 authenticated.
579
581 DAV:all is the union of DAV:authenticated, and DAV:unauthenticated.
582 For a given request, the user matches either DAV:authenticated, or
583 DAV:unauthenticated, but not both.
585 The current user matches a DAV:property principal in a DAV:acl
586 property of a resource only if the identified property of that
587 resource contains a DAV:href that identifies a principal, and the
588 current user is authenticated as being (or being a member of) that
589 principal. For example, if the DAV:property element contained
590 , the current user would match the DAV:property
591 principal only if the current user is authenticated as matching the
592 principal identified by the DAV:owner property of the resource.
594
596 The current user matches DAV:self in a DAV:acl property of the
597 resource only if that resource is a principal object and the
598 current user is authenticated as being that principal.
600
601 5.4.2 ACE Grant and Deny
603 Each DAV:grant or DAV:deny element specifies the set of privileges
604 to be either granted or denied to the specified principal. A
605 DAV:grant or DAV:deny element of the DAV:acl of a resource MUST
606 only contain non-abstract elements specified in the DAV:supported-
607 privilege-set of that resource.
609
610
611
613 5.4.3 ACE Protection
615 If an ACE contains a DAV:protected element, an ACL request without
616 that ACE MUST fail.
618
620 5.4.4 ACE Inheritance
622 The presence of a DAV:inherited element indicates that this ACE is
623 inherited from another resource that is identified by the URL
624 contained in a DAV:href element. An inherited ACE cannot be
625 modified directly, but instead the ACL on the resource from which
626 it is inherited must be modified.
628 Note that ACE inheritance is not the same as ACL initialization.
629 ACL initialization defines the ACL that a newly created resource
630 will use (if not specified). ACE inheritance refers to an ACE that
631 is logically shared - where an update to the resource containing an
632 ACE will affect the ACE of each resource that inherits that ACE.
633 The method by which ACLs are initialized or by which ACEs are
634 inherited is not defined by this document.
636
638 5.5 DAV:acl-semantics
640 This is a read-only property that defines the ACL semantics. These
641 semantics define how multiple ACEs that match the current user are
642 combined, what are the constraints on how ACEs can be ordered, and
643 which principals must have an ACE. A client user interface could
644 use the value of this property to provide feedback to a human
645 operator concerning the impact of proposed changes to an ACL.
646 Alternately, a client could use this property to determine exactly,
647 before submitting an ACL method invocation, what ACL changes it
648 needs to make to accomplish a specific goal (or whether that goal
649 is even achievable on this server).
651 Since it is not practical to require all implementations to use the
652 same ACL semantics, the DAV:acl-semantics property is used to
653 identify the ACL semantics for a particular resource. The DAV:acl-
654 semantics element is defined in section 6.
656 5.6 DAV:principal-collection-set
658 This read-only property contains zero, one, or more URLs that
659 identify a collection principal. It is expected that
660 implementations of this protocol will typically employ a relatively
661 small number of locations in the URL namespace for principal, and
662 collection principals. In cases where this assumption holds, the
663 DAV:principal-collection-set property will contain a small set of
664 URLs identifying the top of collection hierarchy containing
665 multiple principals and collection principals. An access control
666 protocol user agent could use the contents of DAV:principal-
667 collection-set to query the DAV:displayname property (specified in
668 Section 13.2 of [RFC2518]) of all principals on that server,
669 thereby yielding human-readable names for each principal that could
670 be displayed in a user interface.
672
673 Since different servers can control different parts of the URL
674 namespace, different resources on the same host MAY have different
675 DAV:principal-collection-set values. The collections specified in
676 the DAV:principal-collection-set MAY be located on different hosts
677 from the resource. The URLs in DAV:principal-collection-set SHOULD
678 be http or https scheme URLs. For security and scalability reasons,
679 a server MAY report only a subset of the entire set of known
680 collection principals, and therefore clients should not assume they
681 have retrieved an exhaustive listing. Additionally, a server MAY
682 elect to report none of the collection principals it knows about.
684 5.7 Example: PROPFIND to retrieve access control properties
686 The following example shows how access control information can be
687 retrieved by using the PROPFIND method to fetch the values of the
688 DAV:owner, DAV:supported-privilege-set, DAV:current-user-privilege-
689 set, and DAV:acl properties.
691 >> Request <<
693 PROPFIND /top/container/ HTTP/1.1
694 Host: www.foo.org
695 Content-type: text/xml; charset="utf-8"
696 Content-Length: xxx
697 Depth: 0
698 Authorization: Digest username="ejw",
699 realm="users@foo.org", nonce="...",
700 uri="/top/container/", response="...", opaque="..."
702
703
704
705
706
707
708
709 >> Response <<
711 HTTP/1.1 207 Multi-Status
712 Content-Type: text/xml; charset="utf-8"
713 Content-Length: xxx
715
716
719 HTTP/1.1 200 OK
720
721
722 http://www.foo.org/users/gclemm
723
724
725
726
727 Any operation
728
729
730 Read any object
731
732
733
734
735 Write any object
736
737
738 Create an object
739
740
741
742 Update an object
743
744
745
746 Delete an object
747
748
749
750
751 Read the ACL
752
753
754
755 Write the ACL
756
757
758
759
760
761
762
763
764
765
766 http://www.foo.org/users/esedlar
767
768 Eric Sedlar
769
770
771
772
773
774
775
776
777 http://www.foo.org/groups/marketing/
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794 http://www.foo.org/top/
795
796
797
799 The value of the DAV:owner property is a single DAV:href XML
800 element containing the URL of the principal that owns this
801 resource.
803 The value of the DAV:supported-privilege-set property is a tree of
804 supported privileges:
806 DAV:all (aggregate, abstract)
807 |
808 +-- DAV:read
809 +-- DAV:write (aggregate, abstract)
810 |
811 +-- http://www.webdav.org/acl/create
812 +-- http://www.webdav.org/acl/update
813 +-- http://www.webdav.org/acl/delete
814 +-- DAV:read-acl
815 +-- DAV:write-acl
817 The DAV:current-user-privilege-set property contains two
818 privileges, DAV:read, and DAV:read-acl. This indicates that the
819 current authenticated user only has the ability to read the
820 resource, and read the DAV:acl property on the resource.
822 The DAV:acl property contains a set of four ACEs:
824 ACE #1: The principal identified by the URL
825 http://www.foo.org/users/esedlar is granted the DAV:read,
826 DAV:write, and DAV:read-acl privileges.
828 ACE #2: The principals identified by the URL
829 http://www.foo.org/groups/marketing/ are denied the DAV:read
830 privilege. In this example, the principal URL identifies a group,
831 which is represented by a collection principal.
833 ACE #3: In this ACE, the principal is a property principal,
834 specifically the DAV:owner property. When evaluating this ACE, the
835 value of the DAV:owner property is retrieved, and is examined to
836 see if it contains a DAV:href XML element. If so, the URL within
837 the DAV:href element is read, and identifies a principal. In this
838 ACE, the owner is granted DAV:read-acl, and DAV:write-acl
839 privileges.
841 ACE #4: This ACE grants the DAV:all principal (all users) the
842 DAV:read privilege. This ACE is inherited from the resource
843 http://www.foo.org/top/, the parent collection of this resource.
845 6 ACL SEMANTICS
847 The ACL semantics define how multiple ACEs that match the current
848 user are combined, what are the constraints on how ACEs can be
849 ordered, and which principals must have an ACE.
851
853
856 6.1 ACE Combination
858 The DAV:ace-combination element defines how privileges from
859 multiple ACEs that match the current user will be combined to
860 determine the access privileges for that user. Multiple ACEs may
861 match the same user because the same principal can appear in
862 multiple ACEs, because multiple principals can identify the same
863 user, and because one principal can be a member of another
864 principal.
866
870 6.1.1 DAV:first-match ACE Combination
872 The ACEs are evaluated in the order in which they appear in the
873 ACL. If the first ACE that matches the current user does not grant
874 all the privileges needed for the request, the request MUST fail.
876
878 6.1.2 DAV:all-grant-before-any-deny ACE Combination
880 The ACEs are evaluated in the order in which they appear in the
881 ACL. If an evaluated ACE denies a privilege needed for the
882 request, the request MUST fail. If all ACEs have been evaluated
883 without the user being granted all privileges needed for the
884 request, the request MUST fail.
886
888 6.1.3 DAV:specific-deny-overrides-grant ACE Combination
890 All ACEs in the ACL are evaluated. An "individual ACE" is one
891 whose principal identifies the current user. A "group ACE" is one
892 whose principal is a collection that contains a principal that
893 identifies the current user. A privilege is granted if it is
894 granted by an individual ACE and not denied by an individual ACE,
895 or if it is granted by a group ACE and not denied by an individual
896 or group ACE. A request MUST fail if any of its needed privileges
897 are not granted.
899
901 6.2 ACE Ordering
903 The DAV:ace-ordering element defines a constraint on how the ACEs
904 can be ordered in the ACL.
906
908 6.2.1 DAV:deny-before-grant ACE Ordering
910 This element indicates that all deny ACEs must precede all grant
911 ACEs.
913
915 6.3 Required Principals
917 The required principal elements identify which principals must have
918 an ACE defined in the ACL.
920
922 For example, the following element requires that the ACL contain a
923 DAV:owner property ACE:
925
926
927
929 7 ACCESS CONTROL AND EXISTING METHODS
931 This section defines the impact of access control functionality on
932 existing methods.
934 7.1 OPTIONS
936 If the server supports access control, it MUST return "access-
937 control" as a field in the DAV response header from an OPTIONS
938 request on any resource implemented by that server.
940 7.1.1 Example - OPTIONS
942 >> Request <<
944 OPTIONS /foo.html HTTP/1.1
945 Host: www.webdav.org
946 Content-Length: 0
948 >> Response <<
950 HTTP/1.1 200 OK
951 DAV: 1, 2, access-control
952 Allow: OPTIONS, GET, PUT, PROPFIND, PROPPATCH, ACL
954 In this example, the OPTIONS response indicates that the server
955 supports access control and that /foo.html can have its access
956 control list modified by the ACL method.
958 8 ACCESS CONTROL METHODS
960 8.1 ACL
962 The ACL method modifies the DAV:acl property of a resource. A new
963 DAV:acl value must be written in its entirety, including any
964 inherited ACEs. Unless the DAV:acl property of the resource can be
965 updated to be exactly the value specified in the ACL request, the
966 ACL request MUST fail. If a server restricts the set of ACEs
967 visible to the current user via the DAV:acl property, then the ACL
968 request would only replace the set of ACEs visible to the current
969 user, and would not affect any ACE that was not visible.
971 In order to avoid overwriting DAV:acl changes by another client, a
972 client SHOULD acquire a WebDAV lock on the resource before
973 retrieving the DAV:acl property of a resource that it intends on
974 updating.
976 When submitting ACEs, clients MUST NOT include the optional prop
977 element (a child of the principal element). The purpose of this
978 restriction is to limit the scope of effect of the ACL method to
979 just the resource identified by the Request-URI; setting the prop
980 element would additionally require property modification for one or
981 more principal resources.
983 8.1.1 ACL Preconditions
985 An implementation MAY enforce one or more of the following
986 constraints on an ACL request. If the constraint is violated, a
987 403 (Forbidden) response MUST be returned and the indicated XML
988 element MUST be returned in the response body.
990 : An implementation MAY protect an ACE from
991 modification or deletion. For example, some implementations
992 implicitly grant the DAV:owner of a resource DAV:read-acl and
993 DAV:write-acl privileges, and this cannot be changed by a client.
995 : An implementation MAY limit the number of
996 ACEs in an ACL. However, ACL-compliant servers MUST support at
997 least one ACE granting privileges to a single principal, and one
998 ACE granting privileges to a collection principal.
1000 : All non-inherited ACEs
1001 MUST precede all inherited ACEs.
1003 : All non-inherited deny ACEs MUST
1004 precede all non-inherited grant ACEs.
1006 If the following precondition is not met, the server MUST return a
1007 409 (Conflict) response, and the indicated XML element MUST be
1008 returned in the response body:
1010 : Inherited ACEs MUST exist on a parent
1011 resource.
1013 8.1.2 Example: the ACL method
1015 In the following example, user "fielding", authenticated by
1016 information in the Authorization header, grants the principal
1017 identified by the URL http://www.foo.org/users/esedlar (i.e., the
1018 user "esedlar") read and write privileges, grants the owner of the
1019 resource read-acl and write-acl privileges, and grants everyone
1020 read privileges inherited from the parent collection
1021 http://www.foo.bar/top/.
1023 >> Request <<
1025 ACL /top/container/ HTTP/1.1
1026 Host: www.foo.org
1027 Content-Type: text/xml; charset="utf-8"
1028 Content-Length: xxxx
1029 Authorization: Digest username="fielding",
1030 realm="users@foo.org", nonce="...",
1031 uri="/top/container/", response="...", opaque="..."
1033
1034
1035
1036
1037 http://www.foo.org/users/esedlar
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055 http://www.foo.org/top/
1056
1058 >> Response <<
1060 HTTP/1.1 200 OK
1062 8.1.3 Example: ACL method failure due to omission of protected ACE
1064 In the following request, user "fielding", authenticated by
1065 information in the Authorization header, attempts to grant the
1066 principal identified by the URL http://www.foo.org/users/esedlar
1067 (i.e., the user "esedlar") read privileges. Prior to the request,
1068 the DAV:acl property on the resource contained a protected ACE (see
1069 Section 5.4.3) granting DAV:owner the DAV:read-acl and DAV:write-
1070 acl privileges. The ACL method invocation fails because this
1071 protected ACE is omitted, thus violating the semantics of ACE
1072 protection..
1074 >> Request <<
1076 ACL /top/container/ HTTP/1.1
1077 Host: www.foo.org
1078 Content-Type: text/xml; charset="utf-8"
1079 Content-Length: xxxx
1080 Authorization: Digest username="fielding",
1081 realm="users@foo.org", nonce="...",
1082 uri="/top/container/", response="...", opaque="..."
1084
1085
1086
1087
1088 http://www.foo.org/users/esedlar
1089
1090
1091
1092
1093
1095 >> Response <<
1097 HTTP/1.1 403 Forbidden
1098 Content-Type: text/xml; charset="utf-8"
1099 Content-Length: xxx
1101
1102
1104 8.1.4 Example: ACL method failure due to inherited ACEs preceding non-
1105 inherited ACEs
1107 In the following request, user "ejw", authenticated by information
1108 in the Authorization header, tries to change the access control
1109 list on the resource http://www.foo.org/top/index.html. This
1110 resource has two inherited ACEs.
1112 Inherited ACE #1 grants the principal identified by URL
1113 http://www.foo.org/users/ejw (i.e., the user "ejw")
1114 http://www.foo.org/privs/write-all and DAV:read-acl privileges. On
1115 this server, http://www.foo.org/privs/write-all is an aggregate
1116 privilege containing DAV:write, and DAV:write-acl.
1118 Inherited ACE #2 grants principal DAV:all the DAV:read privilege.
1120 The request attempts to add a third ACE, granting the principal
1121 identified by the URL http://www.foo.org/users/gclemm (i.e., the
1122 user �gclemm�) DAV:write permission, but in the request places the
1123 inherited ACEs before the non-inherited ACEs, causing an error on
1124 this specific server implementation. Note that on a different
1125 implementation, this request might be accepted.
1127 >> Request <<
1129 ACL /top/index.html HTTP/1.1
1130 Host: www.foo.org
1131 Content-Type: text/xml; charset="utf-8"
1132 Content-Length: xxxx
1133 Authorization: Digest username="ejw",
1134 realm="users@foo.org", nonce="...",
1135 uri="/top/index.html", response="...", opaque="..."
1137
1138
1139
1140
1141 http://www.foo.org/users/ejw
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156 http://www.foo.org/users/gclemm
1157
1158
1159
1160
1162 >> Response <<
1164 HTTP/1.1 403 Forbidden
1165 Content-Type: text/xml; charset="utf-8"
1166 Content-Length: xxx
1168
1169
1171 8.1.5 Example: ACL method failure due to an attempt to set grant and deny
1172 in a single ACE.
1174 In this example, user "ygoland", authenticated by information in
1175 the Authorization header, tries to change the access control list
1176 on the resource http://www.foo.org/diamond/engagement-ring.gif. The
1177 ACL request includes a single, syntactically and semantically
1178 incorrect ACE, which attempts to grant the collection principal
1179 identified by the URL http://www.foo.org/users/friends/ DAV:read
1180 privilege and deny the principal identified by URL
1181 http://www.foo.org/users/ygoland-so (i.e., the user "ygoland-so")
1182 DAV:read privilege. However, it is illegal to have multiple
1183 principal elements, as well as both a grant and deny element in the
1184 same ACE, so the request fails due to poor syntax.
1186 >> Request <<
1188 ACL /diamond/engagement-ring.gif HTTP/1.1
1189 Host: www.foo.org
1190 Content-Type: text/xml; charset="utf-8"
1191 Content-Length: xxxx
1192 Authorization: Digest username="ygoland",
1193 realm="users@foo.org", nonce="...",
1194 uri="/diamond/engagement-ring.gif", response="...", opaque="..."
1196
1197
1198
1199
1200 http://www.foo.org/users/friends/
1201
1202
1203
1204 http://www.foo.org/users/ygoland-so
1205
1206
1207
1208
1210 >> Response <<
1212 HTTP/1.1 400 Bad Request
1213 Content-Length: 0
1215 Note that if the request had been divided into two ACEs, one to
1216 grant, and one to deny, the request would have been syntactically
1217 well formed.
1219 9 INTERNATIONALIZATION CONSIDERATIONS
1221 In this specification, the only human-readable content can be found
1222 in the description XML element, found within the DAV:supported-
1223 privilege-set property. This element contains a human-readable
1224 description of the capabilities controlled by a privilege. As a
1225 result, the description element must be capable of representing
1226 descriptions in multiple character sets. Since the description
1227 element is found within a WebDAV property, it is represented on-
1228 the-wire as XML [REC-XML], and hence can leverage XML's language
1229 tagging and character set encoding capabilities. Specifically, XML
1230 processors must, at minimum, be able to read XML elements encoded
1231 using the UTF-8 [UTF-8] encoding of the ISO 10646 multilingual
1232 plane. XML examples in this specification demonstrate use of the
1233 charset parameter of the Content-Type header, as defined in
1234 [RFC3023], as well as the XML "encoding" attribute, which together
1235 provide charset identification information for MIME and XML
1236 processors.
1238 For XML elements other than the description element, it is expected
1239 that implementations will treat the property names, privilege
1240 names, and values as tokens, and convert these tokens into human-
1241 readable text in the user's language and character set when
1242 displayed to a person. Only a generic WebDAV property display
1243 utility would display these values in their raw form to a human
1244 user.
1246 For error reporting, we follow the convention of HTTP/1.1 status
1247 codes, including with each status code a short, English description
1248 of the code (e.g., 200 (OK)). While the possibility exists that a
1249 poorly crafted user agent would display this message to a user,
1250 internationalized applications will ignore this message, and
1251 display an appropriate message in the user's language and character
1252 set.
1254 Further internationalization considerations for this protocol are
1255 described in the WebDAV Distributed Authoring protocol
1256 specification [RFC2518].
1258 10 SECURITY CONSIDERATIONS
1260 Applications and users of this access control protocol should be
1261 aware of several security considerations, detailed below. In
1262 addition to the discussion in this document, the security
1263 considerations detailed in the HTTP/1.1 specification [RFC2616],
1264 the WebDAV Distributed Authoring Protocol specification [RFC2518],
1265 and the XML Media Types specification [RFC3023] should be
1266 considered in a security analysis of this protocol.
1268 10.1 Increased Risk of Compromised Users
1270 In the absence of a mechanism for remotely manipulating access
1271 control lists, if a single user's authentication credentials are
1272 compromised, only those resources for which the user has access
1273 permission can be read, modified, moved, or deleted. With the
1274 introduction of this access control protocol, if a single
1275 compromised user has the ability to change ACLs for a broad range
1276 of other users (e.g., a super-user), the number of resources that
1277 could be altered by a single compromised user increases. This risk
1278 can be mitigated by limiting the number of people who have write-
1279 acl privileges across a broad range of resources.
1281 10.2 Risks of the read-acl and cuprivset Privileges
1283 The ability to read the access privileges (stored in the DAV:acl
1284 property), or the privileges permitted the currently authenticated
1285 user (stored in the DAV:current-user-privilege-set property) on a
1286 resource may seem innocuous, since reading an ACL cannot possibly
1287 affect the resource's state. However, if all resources have world-
1288 readable ACLs, it is possible to perform an exhaustive search for
1289 those resources that have inadvertently left themselves in a
1290 vulnerable state, such as being world-writeable. In particular, the
1291 property retrieval method PROPFIND, executed with Depth infinity on
1292 an entire hierarchy, is a very efficient way to retrieve the
1293 DAV:acl or DAV:current-user-privilege-set properties. Once found,
1294 this vulnerability can be exploited by a denial of service attack
1295 in which the open resource is repeatedly overwritten. Alternately,
1296 writeable resources can be modified in undesirable ways.
1298 To reduce this risk, read-acl privileges should not be granted to
1299 unauthenticated principals, and restrictions on read-acl and
1300 cuprivset privileges for authenticated principals should be
1301 carefully analyzed when deploying this protocol. Access to the
1302 current-user-privilege-set property will involve a tradeoff of
1303 usability versus security. When the current-user-privilege-set is
1304 visible, user interfaces are expected to provide enhanced
1305 information concerning permitted and restricted operations, yet
1306 this information may also indicate a vulnerability that could be
1307 exploited. Deployment of this protocol will need to evaluate this
1308 tradeoff in light of the requirements of the deployment
1309 environment.
1311 11 AUTHENTICATION
1313 Authentication mechanisms defined in WebDAV also apply to this
1314 WebDAV Access Control Protocol, in particular the Basic and Digest
1315 authentication mechanisms defined in [RFC2617].
1317 12 IANA CONSIDERATIONS
1319 This document uses the namespace defined by [RFC2518] for XML
1320 elements. All other IANA considerations mentioned in [RFC2518]
1321 also applicable to WebDAV ACL.
1323 13 INTELLECTUAL PROPERTY
1325 The following notice is copied from RFC 2026, section 10.4, and
1326 describes the position of the IETF concerning intellectual property
1327 claims made against this document.
1329 The IETF takes no position regarding the validity or scope of any
1330 intellectual property or other rights that might be claimed to
1331 pertain to the implementation or use other technology described in
1332 this document or the extent to which any license under such rights
1333 might or might not be available; neither does it represent that it
1334 has made any effort to identify any such rights. Information on
1335 the IETF's procedures with respect to rights in standards-track and
1336 standards-related documentation can be found in BCP-11. Copies of
1337 claims of rights made available for publication and any assurances
1338 of licenses to be made available, or the result of an attempt made
1339 to obtain a general license or permission for the use of such
1340 proprietary rights by implementers or users of this specification
1341 can be obtained from the IETF Secretariat.
1343 The IETF invites any interested party to bring to its attention any
1344 copyrights, patents or patent applications, or other proprietary
1345 rights that may cover technology that may be required to practice
1346 this standard. Please address the information to the IETF
1347 Executive Director.
1349 14 ACKNOWLEDGEMENTS
1351 This protocol is the collaborative product of the WebDAV ACL design
1352 team: Bernard Chester, Geoff Clemm (Rational), Anne Hopkins
1353 (Microsoft), Barry Lind (Xythos), Sean Lyndersay (Microsoft), Eric
1354 Sedlar (Oracle), Greg Stein (Apache.org), and Jim Whitehead (UC
1355 Santa Cruz). The authors are grateful for the detailed review and
1356 comments provided by Jim Amsden, Gino Basso, Murthy Chintalapati,
1357 Dennis Hamilton, Laurie Harper, Ron Jacobs, Chris Knight, and Remy
1358 Maucherat. Prior work on WebDAV access control protocols has been
1359 performed by Yaron Goland, Paul Leach, Lisa Dusseault, Howard
1360 Palmer, and Jon Radoff. We would like to acknowledge the foundation
1361 laid for us by the authors of the WebDAV and HTTP protocols upon
1362 which this protocol is layered, and the invaluable feedback from
1363 the WebDAV working group.
1365 15 REFERENCES
1367 15.1 Normative References
1369 [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate
1370 Requirement Levels." RFC 2119, BCP 14, Harvard, March, 1997.
1372 [REC-XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible
1373 Markup Language (XML)." World Wide Web Consortium Recommendation
1374 REC-xml-19980210. http://www.w3.org/TR/REC-xml-19980210.
1376 [RFC2616] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L.
1377 Masinter, P. Leach, and T. Berners-Lee, "Hypertext Transfer
1378 Protocol -- HTTP/1.1." RFC 2616. U.C.Irvine, Compaq, Xerox,
1379 Microsoft, MIT/LCS, June, 1999.
1381 [RFC2617] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P.
1382 Leach, A. Luotonen, L. Stewart, "HTTP Authentication: Basic and
1383 Digest Access Authentication. " RFC 2617. Northwestern University,
1384 Verisign, AbiSource, Agranat, Microsoft, Netscape, Open Market,
1385 June, 1999.
1387 [RFC2518] Y. Goland, E. Whitehead, A. Faizi, S. R. Carter, D.
1388 Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV." RFC
1389 2518. Microsoft, U.C.Irvine, Netscape, Novell, February, 1999.
1391 [RFC2368] P. Hoffman, L. Masinter, J. Zawinski, "The mailto URL
1392 scheme." RFC 2368. Internet Mail Consortium, Xerox, Netscape, July,
1393 1998.
1395 [RFC2255] T. Howes, M. Smith, "The LDAP URL Format." RFC 2255.
1396 Netscape, December, 1997.
1398 [RFC3023] M. Murata, S. St.Laurent, D. Kohn, "XML Media Types." RFC
1399 3023. IBM Tokyo Research Laboratory, simonstl.com, Skymoon
1400 Ventures, January, 2001.
1402 [UTF-8] F. Yergeau, "UTF-8, a transformation format of Unicode and
1403 ISO 10646." RFC 2279. Alis Technologies. January, 1998.
1405 15.2 Informational References
1407 [RFC2026] S.Bradner, "The Internet Standards Process -- Revision 3."
1408 RFC 2026, BCP 9. Harvard, October, 1996.
1410 16 AUTHORS' ADDRESSES
1412 Geoffrey Clemm
1413 Rational Software
1414 20 Maguire Road
1415 Lexington, MA 02421
1416 Email: geoffrey.clemm@rational.com
1418 Anne Hopkins
1419 Microsoft Corporation
1420 One Microsoft Way
1421 Redmond, WA 98052
1422 Email: annehop@microsoft.com
1424 Eric Sedlar
1425 Oracle Corporation
1426 500 Oracle Parkway
1427 Redwood Shores, CA 94065
1428 Email: esedlar@us.oracle.com
1430 Jim Whitehead
1431 U.C. Santa Cruz
1432 Dept. of Computer Science
1433 Baskin Engineering
1434 1156 High Street
1435 Santa Cruz, CA 95064
1436 Email: ejw@cse.ucsc.edu
1438 17 APPENDICIES
1440 17.1 XML Document Type Definition
1442
1444
1445
1446
1447
1448
1449
1451
1453
1455
1456
1458
1460
1461
1463
1465
1466
1469
1470
1471
1472
1474
1476
1478
1480
1482
1483
1487
1488
1489
1490
1491
1492
1494
1495
1496
1498
1500
1502
1504
1505
1507
1508
1511
1514
1515
1516
1518
1519
1521
1524
1526
1527
1528
1529
1530
1531