idnits 2.17.1 draft-ietf-webdav-redirectref-protocol-02.txt: 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 Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 25 longer pages, the longest (page 1) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 26 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 52 instances of lines with control characters in the document. == There are 11 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (June 17, 2000) is 8714 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) ** Obsolete normative reference: RFC 2396 (ref. 'URI') (Obsoleted by RFC 3986) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' ** Obsolete normative reference: RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2518 (ref. 'WebDAV') (Obsoleted by RFC 4918) -- Possible downref: Non-RFC (?) normative reference: ref. 'B' Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 WEBDAV Working Group J. Slein, Xerox 2 INTERNET DRAFT E.J. Whitehead Jr., UC Irvine 3 J. Davis, CourseNet 4 G. Clemm, Rational 5 C. Fay, FileNet 6 J. Crawford, IBM 7 December 17, 1999 8 Expires June 17, 2000 10 WebDAV Redirect Reference Resources 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with all 15 provisions of Section 10 of RFC2026. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, and 17 its working groups. Note that other groups may also distribute working 18 documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Distribution of this document is unlimited. Please send comments to the 32 Distributed Authoring and Versioning (WebDAV) working group at , which may be joined by sending a message with subject 34 "subscribe" to . 36 Discussions of the WEBDAV working group are archived at URL: 37 . 39 Abstract 41 This is one of a pair of specifications that extend the WebDAV 42 Distributed Authoring Protocol to enable clients to create new access 43 paths to existing resources. The two protocol extensions have very 44 different characteristics that make them useful for different sorts of 45 applications. 47 The present specification defines redirect reference resources. A 48 redirect reference resource is a resource whose default response is an 49 HTTP/1.1 302 (Found) status code, redirecting the client to a different 50 resource, the target resource. A redirect reference makes it possible 51 to access the target resource indirectly, through any URI mapped to the 52 redirect reference resource. There are no integrity guarantees 53 associated with redirect reference resources. 55 The related specification, RFC xxxx, defines bindings, and the BIND 56 method for creating them. Creating a new binding to a resource 57 indirectly creates one or more new URIs mapped to that resource, which 58 can then be used to access it. Servers are required to insure the 59 integrity of any bindings that they allow to be created. 61 Table of Contents 63 1 Notational Conventions........................................3 64 2 Introduction..................................................3 65 3 Terminology...................................................4 66 4 Overview of Redirect Reference Resources......................5 67 5 Creating a Redirect Reference Resource........................6 68 5.1 MKRESOURCE....................................................6 69 5.2 Example: Creating a Redirect Reference Resource with 70 MKRESOURCE....................................................7 71 6 Operations on Redirect Reference Resources....................8 72 6.1 Example: GET on a Redirect Reference Resource.................9 73 6.2 Example: PUT on a Redirect Reference Resource with Apply-To- 74 Redirect-Ref..................................................9 75 6.3 Example: PROPPATCH on a Redirect Reference Resource..........10 76 7 Operations on Collections That Contain Redirect Reference 77 Resources....................................................10 78 7.1 MOVE and DELETE on Collections That Contain Redirect 79 References...................................................11 80 7.2 LOCK on a Collection That Contains Redirect References.......11 81 7.3 Example: PROPFIND on a Collection with Redirect Reference 82 Resources....................................................12 83 7.4 Example: PROPFIND with Apply-To-Redirect-Ref on a Collection 84 with Redirect Reference Resources............................13 85 7.5 Example: COPY on a Collection That Contains a Redirect 86 Reference Resource...........................................15 87 7.6 Example: LOCK on a Collection That Contains a Redirect 88 Reference Resource...........................................15 89 8 Operations on Targets of Redirect Reference Resources........17 90 9 Relative URIs in DAV:reftarget...............................17 91 9.1 Example: Resolving a Relative URI in a MKRESOURCE Request....17 92 9.2 Example: Resolving a Relative URI in a Multi-Status Response.18 93 10 Redirect References to Collections...........................19 94 11 Headers......................................................20 95 11.1 Redirect-Ref Response Header.................................20 96 11.2 Apply-To-Redirect-Ref Request Header.........................20 97 12 Properties...................................................20 98 12.1 reftarget Property...........................................20 99 12.2 location Pseudo-Property.....................................20 100 13 XML Elements.................................................21 101 13.1 redirectref XML Element......................................21 102 14 Extensions to the DAV:response XML Element for Multi-Status 103 Responses....................................................21 104 15 Capability Discovery.........................................21 105 15.1 Example: Discovery of Support for Redirect Reference 106 Resources....................................................22 107 16 Security Considerations......................................22 108 16.1 Privacy Concerns.............................................22 109 16.2 Redirect Loops...............................................22 110 16.3 Redirect Reference Resources and Denial of Service...........23 111 16.4 Private Locations May Be Revealed............................23 112 17 Internationalization Considerations..........................23 113 18 IANA Considerations..........................................24 114 19 Copyright....................................................24 115 20 Intellectual Property........................................24 116 21 Acknowledgements.............................................24 117 22 References...................................................24 118 23 Authors' Addresses...........................................25 119 24 Appendices...................................................25 120 24.1 Appendix 1: Extensions to the WebDAV Document Type 121 Definition...................................................25 123 1 Notational Conventions 125 Since this document describes a set of extensions to the WebDAV 126 Distributed Authoring Protocol [WebDAV], itself an extension to the 127 HTTP/1.1 protocol, the augmented BNF used here to describe protocol 128 elements is exactly the same as described in Section 2.1 of [HTTP]. 129 Since this augmented BNF uses the basic production rules provided in 130 Section 2.2 of [HTTP], these rules apply to this document as well. 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 2 Introduction 138 This is one of a pair of specifications that extend the WebDAV 139 Distributed Authoring Protocol to enable clients to create new access 140 paths to existing resources. This capability is useful for several 141 reasons: 143 URIs of WebDAV-compliant resources are hierarchical and correspond to a 144 hierarchy of collections in resource space. The WebDAV Distributed 145 Authoring Protocol makes it possible to organize these resources into 146 hierarchies, placing them into groupings, known as collections, which 147 are more easily browsed and manipulated than a single flat collection. 148 However, hierarchies require categorization decisions that locate 149 resources at a single location in the hierarchy, a drawback when a 150 resource has multiple valid categories. For example, in a hierarchy of 151 vehicle descriptions containing collections for cars and boats, a 152 description of a combination car/boat vehicle could belong in either 153 collection. Ideally, the description should be accessible from both. 154 Allowing clients to create new URIs that access the existing resource 155 lets them put that resource into multiple collections. 157 Hierarchies also make resource sharing more difficult, since resources 158 that have utility across many collections are still forced into a single 159 collection. For example, the mathematics department at one university 160 might create a collection of information on fractals that contains 161 bindings to some local resources, but also provides access to some 162 resources at other universities. For many reasons, it may be 163 undesirable to make physical copies of the shared resources on the local 164 server: to conserve disk space, to respect copyright constraints, or to 165 make any changes in the shared resources visible automatically. Being 166 able to create new access paths to existing resources in other 167 collections or even on other servers is useful for this sort of case. 169 The redirect reference resources defined here provide a mechanism for 170 creating alternative access paths to existing resources. A redirect 171 reference resource is a resource in one collection whose purpose is to 172 forward requests to another resource (its target), usually in a 173 different collection. In this way, it allows clients to submit requests 174 to the target resource from another collection. It redirects most 175 requests to the target resource using the HTTP 302 (Found) status code, 176 thereby providing a form of mediated access to the target resource. 178 The companion specification, RFC xxxx, defines the BIND method, a 179 different mechanism for allowing clients to create alternative access 180 paths to existing WebDAV-compliant resources. The BIND method lets 181 clients associate a new URI with an existing WebDAV resource. This URI 182 can then be used to submit requests to the resource. Since URIs of 183 WebDAV-compliant resources are hierarchical, and correspond to a 184 hierarchy of collections in resource space, the BIND method also has the 185 effect of adding the resource to a collection. As new URIs are 186 associated with the resource, it appears in additional collections. 188 Redirect references and bindings have very different characteristics: 190 A redirect reference is a resource, and so can have properties and a 191 body of its own. Properties of a redirect reference resource can 192 contain such information as who created the reference, when, and why. 193 Since redirect reference resources are implemented using HTTP 302 194 responses, it generally takes two round trips to submit a request to the 195 intended resource. Servers are not required to enforce the integrity of 196 redirect references. Redirect references work equally well for local 197 resources and for resources that reside on a different server from the 198 reference. 200 By contrast, a BIND request does not create a new resource, but simply 201 makes available a new URI for submitting requests to an existing 202 resource. The new URI is indistinguishable from any other URI when 203 submitting a request to a resource. Only one round trip is needed to 204 submit a request to the intended target. Servers are required to 205 enforce the integrity of the relationships between the new URIs and the 206 resources associated with them. Consequently, it may be very costly for 207 servers to support BIND requests that cross server boundaries. 209 The remainder of this document is structured as follows: Section 3 210 defines terms that will be used throughout the specification. Section 4 211 provides an overview of redirect reference resources. Section 5 212 discusses how to create a redirect reference resource. Section 6 213 defines the semantics of existing methods when applied to redirect 214 reference resources, and Section 7 discusses their semantics when 215 applied to collections that contain redirect reference resources. 216 Sections 8 through 10 discuss several other issues raised by the 217 existence of redirect reference resources. Sections 11 through 14 218 define the new headers, properties, and XML elements required to support 219 redirect reference resources. Section 15 discusses capability 220 discovery. Sections 16 through 18 present the security, 221 internationalization, and IANA concerns raised by this specification. 222 The remaining sections provide a variety of supporting information. 224 3 Terminology 225 The terminology used here follows and extends that in the WebDAV 226 Distributed Authoring Protocol specification [WebDAV]. Definitions of 227 the terms resource, Uniform Resource Identifier (URI), and Uniform 228 Resource Locator (URL) are provided in [URI]. 230 Reference Resource 231 A resource whose purpose is to forward requests to another 232 resource. Reference resources are an alternative mechanism to 233 bindings (defined in [B]) for allowing clients to create multiple 234 URIs that can be used to submit requests to the same resource. 236 Redirect Reference Resource 237 A resource that allows clients to forward requests to another 238 resource using the HTTP 1.1 302 (Found) response mechanism. The 239 client is aware that this type of reference resource is mediating 240 between it and the target resource. 242 Direct Reference Resource 243 Direct Reference Resources are out of scope for this 244 specification, but are defined here for contrast with redirect 245 reference resources. A direct reference resource automatically 246 forwards requests to another resource, in a way that is 247 transparent to the client. 249 Non-Reference Resource 250 A resource that is not a reference to another resource. 252 Target Resource 253 The resource to which requests are forwarded by a reference 254 resource. 256 4 Overview of Redirect Reference Resources 258 For all operations submitted to a redirect reference resource, the 259 default response is a 302 (Found), accompanied by the Redirect-Ref 260 header (defined in Section 11.1 below) and the Location header set to 261 the URI of the target resource. With this information, the client can 262 resubmit the request to the URI of the target resource. 264 A redirect reference resource never automatically forwards requests to 265 its target resource. It is this characteristic that distinguishes 266 redirect reference resource from direct reference resources and from 267 bindings. It is also what insures that redirect reference resources 268 will be simple to implement and that cross-server references will be 269 possible. If the redirect reference resource were required to forward 270 requests automatically, the server would need proxy capabilities in 271 order to support cross-server references. 273 If the client is aware that it is operating on a redirect reference 274 resource, it can resolve the reference by retrieving the reference 275 resource's DAV:reftarget property (defined in Section 12.1 below), whose 276 value contains the URI of the target resource. It can then submit 277 requests to the target resource. 279 A redirect reference resource is a new type of resource. To distinguish 280 redirect reference resources from non-reference resources, a new value 281 of the DAV:resourcetype property (defined in [WebDAV]), DAV:redirectref, 282 is defined in Section 13.1 below. 284 Since a redirect reference resource is a resource, it can have its own 285 properties and body, and methods can be applied to the reference 286 resource as well as to its target resource. The Apply-To-Redirect-Ref 287 request header (defined in Section 11.2 below) is provided so that 288 referencing-aware clients can control whether an operation is applied to 289 the redirect reference resource or to its target resource. The Apply- 290 To-Redirect-Ref header can be used with most requests to redirect 291 reference resources. This header is particularly useful with PROPFIND, 292 to retrieve the reference resource's own properties. 294 5 Creating a Redirect Reference Resource 296 The MKRESOURCE method is used to create new redirect reference 297 resources. As defined in Section 5.1, MKRESOURCE can be used to create 298 a resource of any type other than standard data containers and 299 collections. In order to create a redirect reference resource using 300 MKRESOURCE, the values of two properties must be set in the body of the 301 MKRESOURCE request. The value of DAV:resourcetype MUST be set to 302 DAV:redirectref, a new value of DAV:resourcetype defined in Section 303 13.1. The value of DAV:reftarget MUST be set to the URI of the target 304 resource. 306 Used in this way, the MKRESOURCE method creates a redirect reference 307 resource whose target is identified by the DAV:reftarget property. It 308 creates a new binding between the new redirect reference resource and 309 the last path segment of the Request-URI. The new binding is added to 310 its parent collection, identified by the Request-URI minus its trailing 311 slash (if present) and final segment. 313 5.1 MKRESOURCE 315 The MKRESOURCE method requests the creation of a resource and 316 initialization of its properties. It allows resources other than 317 standard data containers and collections to be created and their 318 properties initialized in one atomic operation. 320 Preconditions: 322 A resource MUST NOT exist at the Request-URI. 324 Request Marshalling: 326 The location of the new resource to be created is specified by the 327 Request-URI. 329 The request body of the MKRESOURCE method MUST consist of the 330 DAV:propertyupdate XML element defined in Section 12.13 of [WebDAV]. 332 Postconditions: 334 If the response status code is 201, a new resource exists at the 335 Request-URI. 337 The body of the new resource is empty. 339 The properties of the new resource are as specified by the 340 DAV:propertyupdate request body, using PROPPATCH semantics. If the 341 DAV:propertyupdate does not specify a DAV:resourcetype, the resource 342 will be a standard data container. 344 If the response status code is not 201, then a new resource is not 345 created at the Request-URI, and any existing resource at the Request-URI 346 is unaffected. 348 Response Marshalling: 350 Responses from a MKRESOURCE request SHOULD NOT be cached, as MKRESOURCE 351 has non-idempotent semantics. 353 The following status codes can be expected in responses to MKRESOURCE: 355 201 (Created): The new resource was successfully created. 357 207 (Multi-Status): This response is generated if an error was 358 encountered while initializing the properties of the resource, in which 359 case the response is as defined in Section 8.2.1 of [WebDAV]. 361 403 (Forbidden): The server does not allow the creation of the requested 362 resource type at the requested location, or the parent collection of the 363 Request-URI exists but cannot accept members. 365 409 (Conflict): A resource cannot be created at the Request-URI because 366 the parent collection for the resource does not exist, or because there 367 is already a resource at that request-URL. 369 423 (Locked): The Request-URI is locked, and the lock token was not 370 passed with the request. 372 507 (Insufficient Storage): The server does not have sufficient space to 373 record the state of the resource. 375 5.2 Example: Creating a Redirect Reference Resource with MKRESOURCE 377 >> Request: 379 MKRESOURCE /~whitehead/dav/spec08.ref HTTP/1.1 380 Host: www.ics.uci.edu 381 Content-Type: text/xml; charset="utf-8" 382 Content-Length: xxx 384 385 386 387 388 389 390 /i-d/draft-webdav-protocol-08.txt 391 392 393 394 396 >> Response: 398 HTTP/1.1 201 Created 400 This request resulted in the creation of a new redirect reference 401 resource at www.ics.uci.edu/~whitehead/dav/spec08.ref, which points to 402 the resource identified by the DAV:reftarget property. In this example, 403 the target resource is identified by the URI http://www.ics.uci.edu/i- 404 d/draft-webdav-protocol-08.txt. The redirect reference resource's 405 DAV:resourcetype property is set to DAV:redirectref. 407 6 Operations on Redirect Reference Resources 409 Although non-referencing-aware clients cannot create reference 410 resources, they should be able to submit requests through the reference 411 resources created by reference-aware WebDAV clients. They should be 412 able to follow any references to their targets. To make this possible, 413 a server that receives any request made via a redirect reference 414 resource MUST return a 302 (Found) status code, unless the request 415 includes an Apply-To-Redirect-Ref header. The client and server MUST 416 follow [HTTP] Section 10.3.3 "302 Found," but with these additional 417 rules: 419 o The Location response header MUST contain an absolute URI that 420 identifies the target of the reference resource. 422 o The response MUST include the Redirect-Ref header. This header 423 allows reference-aware WebDAV clients to recognize the resource as a 424 reference resource and understand the reason for the redirection. 426 A reference-aware WebDAV client can act on this response in one of two 427 ways. It can, like a non-referencing client, resubmit the request to 428 the URI in the Location header in order to operate on the target 429 resource. Alternatively, it can resubmit the request to the URI of the 430 redirect reference resource with the Apply-To-Redirect-Ref header in 431 order to operate on the reference resource itself. If the Apply-To- 432 Redirect-Ref header is present, the request MUST be applied to the 433 reference resource itself, and a 302 response MUST NOT be returned. 435 A reference-aware client may know before submitting its request that the 436 Request-URI identifies a redirect reference resource. In this case, if 437 the client wants to apply the method to the reference resource, it can 438 save the round trip caused by the 302 response by using an Apply-To- 439 Redirect-Ref header in its initial request to the URI. 441 A few methods need additional explanation: 443 The Apply-To-Redirect-Ref header can be used with GET or HEAD to 444 retrieve the entity headers of a redirect reference resource. When 445 Apply-To-Redirect-Ref is used with GET or HEAD, the Redirect-Ref entity 446 header MUST be returned, along with all HTTP headers that make sense for 447 reference resources (for example, Cache-Control, Age, ETag, Expires, and 448 Last-Modified). 450 A redirect reference resource MAY have a body, though none is defined 451 for it in this specification. The PUT method can be used, with Apply- 452 To-Redirect-Ref, to create or replace the body of a redirect reference 453 resource. 455 Since MKCOL and MKRESOURCE fail when applied to existing resources, if 456 the client attempts to resubmit the request to the target resource, the 457 request MUST fail (unless the reference resource is a dangling 458 reference). Similarly, if the client attempts to resubmit the request 459 to the reference resource with an Apply-To-Redirect-Ref header, the 460 request MUST fail. 462 Since ORDERPATCH applies only to collections, an ORDERPATCH request with 463 an Apply-To-Redirect-Ref header on a redirect reference resource MUST 464 fail. 466 6.1 Example: GET on a Redirect Reference Resource 468 >> Request: 470 GET /bar.html HTTP/1.1 471 Host: www.foo.com 473 >> Response: 475 HTTP/1.1 302 Found 476 Location: http://www.svr.com/Internet/xxspec08.html 477 Redirect-Ref: 479 Since /bar.html is a redirect reference resource and the Apply-To- 480 Redirect-Ref header is not included in the request, the response is a 481 302 (Found). The Redirect-Ref header informs a reference-aware client 482 that this is not an ordinary HTTP 1.1 redirect, but is a redirect 483 reference resource. The URI of the target resource is provided in the 484 Location header so that the client can resubmit the request to the 485 target resource. 487 6.2 Example: PUT on a Redirect Reference Resource with Apply-To- 488 Redirect-Ref 490 >> Request: 492 PUT /bar.html HTTP/1.1 493 Host: www.foo.com 494 Apply-To-Redirect-Ref: 495 Content-Type: text/xml; charset="utf-8" 496 Content-Length: xxxx 498 . . . some content . . . 500 >> Response: 502 HTTP/1.1 200 OK 504 Although /bar.html is a redirect reference resource, the presence of the 505 Apply-To-Redirect-Ref header prevents a 302 response, and instead causes 506 the request to be applied to the reference resource. The result in this 507 case is that the reference resource is replaced by a non-reference 508 resource having the content submitted with the request. 510 6.3 Example: PROPPATCH on a Redirect Reference Resource 512 Request: 514 PROPPATCH /bar.html HTTP/1.1 515 Host: www.foo.com 516 Content-Type: text/xml; charset="utf-8" 517 Content-Length: xxxx 519 520 522 523 524 525 Jim Whitehead 526 Roy Fielding 527 528 529 530 531 532 533 535 Response: 537 HTTP/1.1 302 Found 538 Location: http://www.svr.com/Internet/xxspec08.html 539 Redirect-Ref: 541 Since /bar.html is a redirect reference resource and the Apply-To- 542 Redirect-Ref header is not included in the request, the response is a 543 302 (Found). The Redirect-Ref header informs a reference-aware client 544 that this is not an ordinary HTTP 1.1 redirect, but is a redirect 545 reference resource. The URI of the target resource is provided in the 546 Location header so that the client can resubmit the request to the 547 target resource. 549 7 Operations on Collections That Contain Redirect Reference Resources 551 A URI of a redirect reference resource can be an internal member URI of 552 a collection just as the URI of a non-reference resource can. Any 553 operation on a collection with Depth: 1 or Depth: infinity applies to 554 redirect reference resources in the collection just as it applies to any 555 other resources in the collection. The methods that can accept a Depth 556 header are PROPFIND, COPY, MOVE, DELETE, and LOCK. 558 Consistent with the rules in Section 6, the response for each redirect 559 reference encountered while processing a collection MUST be a 302 560 (Found) unless a Apply-To-Redirect-Ref header is included with the 561 request. The overall response will therefore be a 207 (Multi-Status). 562 Since a Location header and Redirect-Ref header cannot be returned for 563 each redirect reference encountered, the same information is provided 564 using properties in the response elements for those resources. The 565 DAV:location pseudo-property and the DAV:resourcetype property MUST be 566 included with the 302 status code. This necessitates an extension to 567 the syntax of the DAV:response element that was defined in [WebDAV]. 568 The extension is defined in Section 14 below. 570 A referencing-aware client can tell from the DAV:resourcetype property 571 that the collection contains a redirect reference resource. The 572 DAV:location pseudo-property contains the absolute URI of the target 573 resource. A referencing-aware client can either use the URI value of 574 the DAV:location pseudo-property to resubmit its request to the target 575 resource, or it can submit the request to the redirect reference 576 resource with Apply-To-Redirect-Ref. 578 It is recommended that future editors of [WebDAV] define the 579 DAV:location pseudo-property in [WebDAV], so that non-referencing 580 clients will also be able to use the response to operate on the target 581 resource. (This will also enable clients to operate on traditional 582 HTTP/1.1 302 responses in Multi-Status responses.) Until then, non- 583 referencing clients will not be able to process 302 responses from 584 redirect reference resources encountered while processing a collection. 586 The Apply-To-Redirect-Ref header (defined in Section 11.2) MAY be used 587 with any request on a collection. If present, it will be applied to all 588 redirect reference resources encountered while processing the 589 collection. 591 7.1 MOVE and DELETE on Collections That Contain Redirect References 593 DELETE removes the binding that corresponds to the Request-URI. MOVE 594 removes that binding and creates a new binding to the same resource. In 595 cases where DELETE and MOVE are applied to a collection, these 596 operations affect all the descendents of the collection, but they do so 597 indirectly. There is no need to visit each descendent in order to 598 process the request. Consequently, even if there are redirect reference 599 resources in a tree that is being deleted or moved, there will be no 302 600 responses from the redirect reference resources. 602 7.2 LOCK on a Collection That Contains Redirect References 604 LOCK poses special problems because it is atomic. An attempt to lock 605 (with Depth: infinity) a collection that contains redirect references 606 will always fail. The Multi-Status response will contain a 302 response 607 for each redirect reference. 609 Reference-aware clients can lock the collection by using Apply-To- 610 Redirect-Ref, and, if desired, lock the targets of the redirect 611 references individually. 613 Non-referencing clients must resort to locking each resource 614 individually. 616 7.3 Example: PROPFIND on a Collection with Redirect Reference Resources 618 Suppose a PROPFIND request with Depth = infinity is submitted to the 619 following collection, with the members shown here: 621 http://www.svr.com/MyCollection/ 622 (non-reference resource) diary.html 623 (redirect reference resource) nunavut 625 >> Request: 627 PROPFIND /MyCollection/ HTTP/1.1 628 Host: www.svr.com 629 Depth: infinity 630 Content-Type: text/xml 631 Content-Length: xxxx 633 634 635 636 637 638 639 641 >> Response: 643 HTTP/1.1 207 Multi-Status 644 Content-Type: text/xml 645 Content-Length: xxxx 647 648 650 651 http://www.svr.com/MyCollection/ 652 653 654 655 diary, interests, hobbies 656 657 HTTP/1.1 200 OK 658 659 660 661 http://www.svr.com/MyCollection/diary.html 662 663 664 665 diary, travel, family, history 666 667 HTTP/1.1 200 OK 668 669 670 671 http://www.svr.com/MyCollection/nunavut 672 HTTP/1.1 302 Found 673 674 675 http://www.inac.gc.ca/art/inuit/ 676 677 678 679 680 682 In this example the Depth header is set to infinity, and the Apply-To- 683 Redirect-Ref header is not used. The collection contains one URI that 684 identifies a redirect reference resource. The response element for the 685 redirect reference resource has a status of 302 (Found), and includes a 686 DAV:prop element with the DAV:location pseudo-property and the 687 DAV:resourcetype property to allow clients to retrieve the properties of 688 its target resource. (The response element for the redirect reference 689 resource does not include the requested properties. The client can 690 submit another PROPFIND request to the URI in the DAV:location pseudo- 691 property to retrieve those properties.) 693 7.4 Example: PROPFIND with Apply-To-Redirect-Ref on a Collection with 694 Redirect Reference Resources 696 Suppose a PROPFIND request with Apply-To-Redirect-Ref and Depth = 697 infinity is submitted to the following collection, with the members 698 shown here: 700 /MyCollection/ 701 (non-reference resource) diary.html 702 (redirect reference resource) nunavut 704 >> Request: 706 PROPFIND /MyCollection/ HTTP/1.1 707 Host: www.svr.com 708 Depth: infinity 709 Apply-To-Redirect-Ref: 710 Content-Type: text/xml 711 Content-Length: xxxx 713 714 715 716 717 718 719 720 >> Response: 722 HTTP/1.1 207 Multi-Status 723 Content-Type: text/xml 724 Content-Length: xxxx 726 727 728 729 http://www.svr.com/MyCollection/ 730 731 732 733 734 HTTP/1.1 200 OK 735 736 737 738 HTTP/1.1 404 Not Found 739 740 741 742 http://www.svr.com/MyCollection/diary.html 743 744 745 746 747 HTTP/1.1 200 OK 748 749 750 751 HTTP/1.1 404 Not Found 752 753 754 755 http://www.svr.com/MyCollection/nunavut 756 757 758 759 760 http://www.inac.gc.ca/art/inuit/ 761 762 763 HTTP/1.1 200 OK 764 765 766 768 Since the Apply-To-Redirect-Ref header is present, the response shows 769 the properties of the redirect reference resource in the collection 770 rather than the properties of its target. The Apply-To-Redirect-Ref 771 header also prevents a 302 response from being returned for the redirect 772 reference resource. 774 7.5 Example: COPY on a Collection That Contains a Redirect Reference 775 Resource 777 Suppose a COPY request is submitted to the following collection, with 778 the members shown: 780 /MyCollection/ 781 (non-reference resource) diary.html 782 (redirect reference resource) nunavut with target 783 /Someplace/nunavut.map 785 >> Request: 787 COPY /MyCollection/ HTTP/1.1 788 Host: www.svr.com 789 Depth: infinity 790 Destination: http://www.svr.com/OtherCollection/ 792 >> Response: 794 HTTP/1.1 207 Multi-Status 795 Content-Type: text/xml; charset="utf-8" 796 Content-Length: xxx 798 799 800 801 http://www.svr.com/MyCollection/nunavut 802 HTTP/1.1 302 Found 803 804 805 806 http://www.svr.com//Someplace/nunavut.map 807 808 809 810 811 812 814 In this case, since /MyCollection/nunavut is a redirect reference 815 resource, the COPY operation was only a partial success. The redirect 816 reference resource was not copied, but a 302 response was returned for 817 it. So the resulting collection is as follows: 819 /OtherCollection/ 820 (non-reference resource) diary.html 822 7.6 Example: LOCK on a Collection That Contains a Redirect Reference 823 Resource 825 Suppose a LOCK request is submitted to the following collection, with 826 the members shown: 828 /MyCollection/ 829 (non-reference resource) diary.html 830 (redirect reference resource) nunavut 832 >> Request: 834 LOCK /MyCollection/ HTTP/1.1 835 Host: www.svr.com 836 Content-Type: text/xml 837 Content-Length: nnnn 838 Authorizaton: Digest username="jas", 839 realm=jas@webdav.sb.aol.com, nonce=". . . ", 840 uri="/MyCollection/tuva", 841 response=". . . ", opaque=". . . " 843 844 845 846 847 848 http://www.svr.com/~jas/contact.html 849 850 852 >> Response: 854 HTTP/1.1 207 Multi-Status 855 Content-Type: text/xml 856 Content-Length: nnnn 858 859 860 861 http://www.svr.com/MyCollection/ 862 863 864 HTTP/1.1 424 Failed Dependency 865 866 867 868 http://www.svr.com/MyCollection/diary.html 869 HTTP/1.1 424 Failed Dependency 870 871 872 http://www.svr.com/MyCollection/nunavut 873 HTTP/1.1 302 Found 874 875 876 http://www.inac.gc.ca/art/inuit/ 877 878 879 880 881 883 The server returns a 302 response code for the redirect reference 884 resource in the collection. Consequently, neither the collection nor 885 any of the resources identified by its internal member URIs were locked. 886 A referencing-aware client can submit a separate LOCK request to the URI 887 in the DAV:location pseudo-property returned for the redirect reference 888 resource, and can resubmit the LOCK request with the Apply-To-Redirect- 889 Ref header to the collection. At that point both the reference resource 890 and its target resource will be locked (as well as the collection and 891 all the resources identified by its other members). 893 8 Operations on Targets of Redirect Reference Resources 895 Operations on targets of redirect reference resources have no effect on 896 the reference resource. 898 9 Relative URIs in DAV:reftarget 900 The URI in the href in a DAV:reftarget property MAY be a relative URI. 901 In this case, the base URI to be used for resolving the relative URI to 902 absolute form is the URI used in the HTTP message to identify the 903 redirect reference resource to which the DAV:reftarget property belongs. 905 When DAV:reftarget occurs in the body of a MKRESOURCE request, the base 906 URI is constructed as follows: Its scheme component is "http", its 907 authority component is the value of the Host header in the request, and 908 its path component is the Request-URI in the request. See Section 5 of 909 [URI] for a discussion of relative URI references and how to resolve 910 them. 912 When DAV:reftarget appears in the context of a Multi-Status response, it 913 is in a DAV:response element that contains a single DAV:href element. 914 The value of this DAV:href element serves as the base URI for resolving 915 a relative URI in DAV:reftarget. The value of DAV:href may itself be 916 relative, in which case it must be resolved first in order to serve as 917 the base URI for the relative URI in DAV:reftarget. If the DAV:href 918 element is relative, its base URI is constructed from the scheme 919 component "http", the value of the Host header in the request, and the 920 request-URI. 922 9.1 Example: Resolving a Relative URI in a MKRESOURCE Request 924 >> Request: 926 MKRESOURCE /north/inuvik HTTP/1.1 927 Host: www.somehost.edu 928 Content-Type: text/xml; charset="utf-8" 929 Content-Length: xxx 931 932 933 934 935 936 937 mapcollection/inuvik.gif 938 940 941 942 944 >> Response: 946 HTTP/1.1 201 Created 948 In this example, the base URI is http://www.somehost.edu/north/inuvik. 949 Then, following the rules in [URI] Section 5, the relative URI in 950 DAV:reftarget resolves to the absolute URI 951 http://www.somehost.edu/north/mapcollection/inuvik.gif. 953 9.2 Example: Resolving a Relative URI in a Multi-Status Response 955 >> Request: 957 PROPFIND /geog/ HTTP/1.1 958 Host: www.xxsvr.com 959 Apply-To-Redirect-Ref: 960 Depth: 1 961 Content-Type: text/xml 962 Content-Length: nnn 964 965 966 967 968 969 970 972 >> Response: 974 HTTP/1.1 207 Multi-Status 975 Content-Type: text/xml 976 Content-Length: nnn 978 979 980 981 /geog/ 982 983 984 985 986 HTTP/1.1 200 OK 987 988 989 990 HTTP/1.1 404 Not Found 991 992 993 994 /geog/stats.html 995 996 997 998 statistics/population/1997.html 999 1000 1001 HTTP/1.1 200 OK 1002 1003 1004 1006 In this example, the relative URI statistics/population/1997.html is 1007 returned as the value of reftarget for the reference resource identified 1008 by href /geog/stats.html. The href is itself a relative URI, which 1009 resolves to http://www.xxsrv.com/geog/stats.html. This is the base URI 1010 for resolving the relative URI in reftarget. The absolute URI of 1011 reftarget is http://www.xxsrv.com/geog/statistics/population/1997.html. 1013 10 Redirect References to Collections 1015 In a Request-URI /segment1/segment2/segment3, any of the three segments 1016 may identify a redirect reference resource. (See [URI], Section 3.3, 1017 for definitions of "path" and "segment".) If any segment in a Request- 1018 URI identifies a redirect reference resource, the response is a 302. 1019 The value of the Location header in the 302 response is as follows: 1021 The leftmost path segment of the request-URI that identifies a redirect 1022 reference resource, together with all path segments and separators to 1023 the left of it, is replaced by the value of the redirect reference 1024 resource's DAV:reftarget property (resolved to an absolute URI). The 1025 remainder of the request-URI is concatenated to this path. 1027 Note: If the DAV:reftarget property ends with a "/" and the remainder of 1028 the Request-URI is non-empty (and therefore must begin with a "/"), the 1029 final "/" in the DAV:reftarget property is dropped before the remainder 1030 of the Request-URI is appended. 1032 Consider Request-URI /x/y/z.html. Suppose that /x/ is a redirect 1033 reference resource whose target resource is collection /a/, which 1034 contains redirect reference resource y whose target resource is 1035 collection /b/, which contains redirect reference resource z.html whose 1036 target resource is /c/d.html. 1038 /x/ -----> /a/ 1039 /a/y/ -----> /b/ 1040 /b/z.html -----> /c/d.html 1042 In this case the client must follow up three separate 302 responses 1043 before finally reaching the target resource. The server responds to the 1044 initial request with a 302 with Location: /a/y/z.html, and the client 1045 resubmits the request to /a/y/z.html. The server responds to this 1046 request with a 302 with Location: /b/z.html, and the client resubmits 1047 the request to /b/z.html. The server responds to this request with a 1048 302 with Location: /c/d.html, and the client resubmits the request to 1049 /c/d.html. This final request succeeds. 1051 11 Headers 1053 11.1 Redirect-Ref Response Header 1055 Redirect-Ref = "Redirect-Ref:" 1057 The Redirect-Ref header is used in all 302 responses from redirect 1058 reference resources. Its presence informs reference-aware clients that 1059 the response is not a plain HTTP/1.1 redirect, but is a response from a 1060 redirect reference resource. 1062 11.2 Apply-To-Redirect-Ref Request Header 1064 Apply-To-Redirect-Ref = "Apply-To-Redirect-Ref" ":" 1066 The optional Apply-To-Redirect-Ref header can be used on any request to 1067 a redirect reference resource. When it is used, the request MUST be 1068 applied to the reference resource itself, and a 302 response MUST NOT be 1069 returned. 1071 If the Apply-To-Redirect-Ref header is used on a request to any other 1072 sort of resource besides a redirect reference resource, the server 1073 SHOULD ignore it. 1075 12 Properties 1077 12.1 reftarget Property 1079 Name: reftarget 1080 Namespace: DAV: 1081 Purpose: A property of redirect reference resources that provides an 1082 efficient way for clients to discover the URI of the target 1083 resource. This is a read-only property after its initial 1084 creation. Its value can only be set in a MKRESOURCE request. 1085 Value: href containing the URI of the target resource. This value 1086 MAY be a relative URI. The reftarget property can occur in 1087 the entity bodies of MKRESOURCE requests and of responses to 1088 PROPFIND requests. 1090 1092 12.2 location Pseudo-Property 1094 Name: location 1095 Namespace: DAV: 1096 Purpose: For use with 302 (Found) response codes in Multi-Status 1097 responses. It contains the absolute URI of the temporary 1098 location of the resource. In the context of redirect 1099 reference resources, this value is the absolute URI of the 1100 target resource. It is analogous to the Location header in 1101 HTTP 302 responses defined in [HTTP] Section 10.3.3 "302 1102 Found." Including the location pseudo-property in a Multi- 1103 Status response requires an extension to the syntax of the 1104 DAV:response element defined in [WebDAV], which is defined 1105 in Section 14 below. This pseudo-property is not expected 1106 to be stored on the reference resource. It is modeled as a 1107 property only so that it can be returned inside a DAV:prop 1108 element in a Multi-Status response. 1109 Value: href containing the absolute URI of the target resource. 1111 1113 13 XML Elements 1115 13.1 redirectref XML Element 1117 Name: redirectref 1118 Namespace: DAV: 1119 Purpose: Used as the value of the DAV:resourcetype property to 1120 specify that the resource type is a redirect reference 1121 resource. 1123 1125 14 Extensions to the DAV:response XML Element for Multi-Status Responses 1127 As described in Section 7, the DAV:location pseudo-property and the 1128 DAV:resourcetype property may be returned in the DAV:response element of 1129 a 207 Multi-Status response, to allow clients to resubmit their requests 1130 to the target resource of a redirect reference resource. 1132 Whenever these properties are included in a Multi-Status response, they 1133 are placed in a DAV:prop element associated with the href to which they 1134 apply. This structure provides a framework for future extensions by 1135 other standards that may need to include additional properties in their 1136 responses. 1138 Consequently, the definition of the DAV:response XML element changes to 1139 the following: 1141 1144 15 Capability Discovery 1146 Sections 9.1 and 15 of [WebDAV] describe the use of compliance classes 1147 with the DAV header in responses to OPTIONS, to indicate which parts of 1148 the WebDAV Distributed Authoring protocols the resource supports. This 1149 specification defines an OPTIONAL extension to [WebDAV]. It defines a 1150 new compliance class, called redirectrefs, for use with the DAV header 1151 in responses to OPTIONS requests. If a resource does support redirect 1152 references, its response to an OPTIONS request may indicate that it 1153 does, by listing the new redirectrefs compliance class in the DAV 1154 headerand by listing the MKRESOURCE method as one it supports. 1156 When responding to an OPTIONS request, any type of resource can include 1157 redirectrefs in the value of the DAV header. Doing so indicates that 1158 the server permits a redirect reference resource at the request URI. 1160 15.1 Example: Discovery of Support for Redirect Reference Resources 1162 >> Request: 1164 OPTIONS /somecollection/someresource HTTP/1.1 1165 HOST: somehost.org 1167 >> Response: 1169 HTTP/1.1 200 OK 1170 Date: Tue, 20 Jan 1998 20:52:29 GMT 1171 Connection: close 1172 Accept-Ranges: none 1173 Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL, 1174 PROPFIND, PROPPATCH, LOCK, UNLOCK, MKRESOURCE 1175 Public: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL, 1176 PROPFIND, PROPPATCH, LOCK, UNLOCK, BIND, MKRESOURCE, ORDERPATCH 1177 DAV: 1, 2, redirectrefs 1179 The DAV header in the response indicates that the resource 1180 /somecollection/someresource is level 1 and level 2 compliant, as 1181 defined in [WebDAV]. In addition, /somecollection/someresource supports 1182 redirect reference resources. The Allow header indicates that 1183 MKRESOURCE requests can be submitted to /somecollection/someresource. 1184 The Public header shows that other Request-URIs on the server support 1185 additional methods. 1187 16 Security Considerations 1189 This section is provided to make WebDAV applications aware of the 1190 security implications of this protocol. 1192 All of the security considerations of HTTP/1.1 and the WebDAV 1193 Distributed Authoring Protocol specification also apply to this protocol 1194 specification. In addition, redirect reference resources introduce 1195 several new security concerns and increase the risk of some existing 1196 threats. These issues are detailed below. 1198 16.1 Privacy Concerns 1200 By creating redirect reference resources on a trusted server, it is 1201 possible for a hostile agent to induce users to send private information 1202 to a target on a different server. This risk is mitigated somewhat, 1203 since clients are required to notify the user of the redirection for any 1204 request other than GET or HEAD. (See [HTTP], Section 10.3.3 302 Found.) 1206 16.2 Redirect Loops 1208 Although redirect loops were already possible in HTTP 1.1, the 1209 introduction of the MKRESOURCE method creates a new avenue for clients 1210 to create loops accidentally or maliciously. If the reference resource 1211 and its target are on the same server, the server may be able to detect 1212 MKRESOURCE requests that would create loops. See also [HTTP], Section 1213 10.3 "Redirection 3xx." 1214 16.3 Redirect Reference Resources and Denial of Service 1216 Denial of service attacks were already possible by posting URLs that 1217 were intended for limited use at heavily used Web sites. The 1218 introduction of MKRESOURCE creates a new avenue for similar denial of 1219 service attacks. Clients can now create redirect reference resources at 1220 heavily used sites to target locations that were not designed for heavy 1221 usage. 1223 16.4 Private Locations May Be Revealed 1225 There are several ways that redirect reference resources may reveal 1226 information about directory structures. First, the DAV:reftarget 1227 property of every redirect reference resource contains the URI of the 1228 target resource. Anyone who has access to the reference resource can 1229 discover the directory path that leads to the target resource. The 1230 owner of the target resource may have wanted to limit knowledge of this 1231 directory structure. 1233 Sufficiently powerful access control mechanisms can control this risk to 1234 some extent. Property-level access control could prevent users from 1235 examining the DAV:reftarget property. (The Location header returned in 1236 responses to requests on redirect reference resources reveals the same 1237 information, however.) In some environments, the owner of a resource 1238 might be able to use access control to prevent others from creating 1239 references to that resource. 1241 This risk is no greater than the similar risk posed by HTML links. 1243 17 Internationalization Considerations 1245 This specification follows the practices of [WebDAV] in encoding all 1246 human-readable content using XML [XML] and in the treatment of names. 1247 Consequently, this specification complies with the IETF Character Set 1248 Policy [RFC2277]. 1250 WebDAV applications MUST support the character set tagging, character 1251 set encoding, and the language tagging functionality of the XML 1252 specification. This constraint ensures that the human-readable content 1253 of this specification complies with [RFC2277]. 1255 As in [WebDAV}, names in this specification fall into three categories: 1256 names of protocol elements such as methods and headers, names of XML 1257 elements, and names of properties. Naming of protocol elements follows 1258 the precedent of HTTP, using English names encoded in USASCII for 1259 methods and headers. The names of XML elements used in this 1260 specification are English names encoded in UTF-8. 1262 For error reporting, [WebDAV] follows the convention of HTTP/1.1 status 1263 codes, including with each status code a short, English description of 1264 the code (e.g., 423 Locked). Internationalized applications will ignore 1265 this message, and display an appropriate message in the user's language 1266 and character set. 1268 This specification introduces no new strings that are displayed to users 1269 as part of normal, error-free operation of the protocol. 1271 For rationales for these decisions and advice for application 1272 implementors, see [WebDAV]. 1274 18 IANA Considerations 1276 This document uses the namespaces defined by [WebDAV] for properties and 1277 XML elements. All other IANA considerations mentioned in [WebDAV] also 1278 apply to this document. 1280 19 Copyright 1282 To be supplied by the RFC Editor. 1284 20 Intellectual Property 1286 To be supplied by the RFC Editor. 1288 21 Acknowledgements 1290 This draft has benefited from thoughtful discussion by Jim Amsden, Peter 1291 Carlson, Steve Carter, Tyson Chihaya, Ken Coar, Ellis Cohen, Bruce 1292 Cragun, Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, Roy 1293 Fielding, Yaron Goland, Fred Hitt, Alex Hopmann, James Hunt, Marcus 1294 Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare, Daniel LaLiberte, 1295 Steve Martin, Larry Masinter, Jeff McAffer, Surendra Koduru Reddy, Max 1296 Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, John Stracke, John 1297 Tigue, John Turner, Kevin Wiggen, and others. 1299 22 References 1301 [RFC2277] H.T. Alvestrand, "IETF Policy on Character Sets and 1302 Languages." RFC 2277, BCP 18. Uninett. January, 1998. 1304 [URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource 1305 Identifiers (URI): Generic Syntax." RFC 2396. MIT/LCS, U.C. Irvine, 1306 Xerox. August, 1998. 1308 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1309 Levels." RFC 2119, BCP 14. Harvard University. March, 1997. 1311 [XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible Markup 1312 Language (XML)." World Wide Web Consortium Recommendation REC-xml- 1313 19980210. http://www.w3.org/TR/1998/REC-xml-19980210. 1315 [HTTP] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 1316 Leach, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1." RFC 1317 2616. UC Irvine, Compaq, W3C, Xerox, Microsoft. June, 1999. 1319 [WebDAV] Y. Y. Goland, E. J. Whitehead, Jr., A. Faizi, S. R. Carter, D. 1320 Jensen, "HTTP Extensions for Distributed Authoring - WebDAV." RFC 2518. 1321 Microsoft, U.C. Irvine, Netscape, Novell. February, 1999. 1323 [B] J. Slein, E.J. Whitehead Jr., J. Davis, G. Clemm, C. Fay, J. 1325 Crawford, "WebDAV Bindings." Internet Draft (work in progress) draft- 1326 ietf-webdav-binding-protocol-02. Xerox, UC Irvine, CourseNet, Rational, 1327 FileNet, IBM. December, 1999. 1329 23 Authors' Addresses 1331 J. Slein 1332 Xerox Corporation 1333 800 Phillips Road, 105-50C 1334 Webster, NY 14580 1335 Email: jslein@crt.xerox.com 1337 E. J. Whitehead, Jr. 1338 Dept. of Information and Computer Science 1339 University of California, Irvine 1340 Irvine, CA 92697-3425 1341 Email: ejw@ics.uci.edu 1343 J. Davis 1344 CourseNet Systems 1345 170 Capp Street 1346 San Francisco, CA 94110 1347 Email: jrd3@alum.mit.edu 1349 G. Clemm 1350 Rational Software Corporation 1351 20 Maguire Road 1352 Lexington, MA 02173-3104 1353 Email: gclemm@rational.com 1355 C. Fay 1356 FileNet Corporation 1357 3565 Harbor Boulevard 1358 Costa Mesa, CA 92626-1420 1359 Email: cfay@filenet.com 1361 J. Crawford 1362 IBM Research 1363 P.O. Box 704 1364 Yorktown Heights, NY 10598 1365 Email: ccjason@us.ibm.com 1367 24 Appendices 1369 24.1 Appendix 1: Extensions to the WebDAV Document Type Definition 1371 1372 1373 1374 1375 1376 1377 1379 Expires June 17, 2000