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