idnits 2.17.1 draft-ietf-webdav-collection-protocol-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 24 longer pages, the longest (page 1) being 59 lines 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 227 instances of too long lines in the document, the longest one being 13 characters in excess of 72. ** There are 105 instances of lines with control characters in the document. ** The abstract seems to contain references ([WebDAV]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 9 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 206: '... A server MUST advertise its co...' RFC 2119 keyword, line 311: '... resources MUST have the value r...' RFC 2119 keyword, line 319: '... MUST have these properties. A...' RFC 2119 keyword, line 351: '...esses a MKREF request, it MUST set the...' RFC 2119 keyword, line 355: '...esses a MKREF request, it MUST set the...' (49 more instances...) 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 (January 31, 1999) is 9216 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: 'Alvestrand' is mentioned on line 1259, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'WebDAV' -- Possible downref: Non-RFC (?) normative reference: ref. 'DASL' -- Possible downref: Non-RFC (?) normative reference: ref. 'WebDAVReq' ** Obsolete normative reference: RFC 2068 (ref. 'HTTP') (Obsoleted by RFC 2616) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 6 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 J. Davis, Xerox 3 A. Babich, FileNet 4 E.J. Whitehead Jr., UC Irvine 5 July 31, 1998 6 Expires January 31, 1999 8 WebDAV Advanced Collections Protocol 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or made obsolete by other 19 documents at any time. It is inappropriate to use Internet-Drafts 20 as reference material or to cite them other than as "work in 21 progress". 23 To view the entire list of current Internet-Drafts, please check 24 the "1id-abstracts.txt" listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 26 (Northern Europe), ftp.nis.garr.it (Southern Europe),munnari.oz.au 27 (Pacific Rim), ftp.ietf.org (US EastCoast), or ftp.isi.edu (US West 28 Coast). 30 Distribution of this document is unlimited. Please send comments 31 to the Distributed Authoring and Versioning (WebDAV) working group 32 at , which may be joined by sending a 33 message with subject "subscribe" to . 36 Discussions of the WEBDAV working group are archived at URL: 37 . 39 Abstract 41 The base WebDAV protocol [WebDAV] provides basic support for 42 collections. It defines a MKCOL method for creating collections 43 and specifies how other HTTP and WebDAV methods interact with 44 collections. It supports internal members of collections, which it 45 defines as members whose URIs are immediately relative to the URI 46 of the collection. 48 Many applications, however, need more powerful collections. There 49 are two areas in particular where more powerful functionality is 50 often needed: referential resources and ordering. 52 This draft specifies extensions to the base WebDAV protocol to 53 support these more powerful collections. 55 Table of Contents 57 1 Terminology 3 58 2 Introduction 4 59 3 Referential Resources 4 60 3.1 Scope 4 61 3.2 Overview 6 62 3.3 Creating Referential Resources 6 63 3.3.1 The MKREF Method 6 64 3.3.2 Status Codes 7 65 3.3.3 Example 8 66 3.4 Deleting Referential Resources 8 67 3.4.1 The DELREF Method 8 68 3.4.2 Status Codes 8 69 3.4.3 Example 8 70 3.4.4 Design Rationale 8 71 3.5 Listing Referential Members of a Collection 9 72 3.6 Other WebDAV Operations on Indirect References 9 73 3.7 HTTP Operations on Indirect References 10 74 3.8 Operations on Targets of References 11 75 4 Ordered Collections 11 76 4.1 Overview 11 77 4.2 Creating an Ordered Collection 11 78 4.2.1 Overview 11 79 4.2.2 Status Codes 12 80 4.2.3 Example 12 81 4.3 Setting the Position of a Collection Member 12 82 4.3.1 Overview 12 83 4.3.2 Status Codes 13 84 4.3.3 Examples 13 85 4.4 Changing the Semantics of a Collection Ordering 14 86 4.5 Changing the Position of a Collection Member 14 87 4.5.1 The ORDERPATCH Method 14 88 4.5.2 Status Codes 14 89 4.5.3 Example 14 90 4.5.4 Design Rationale 15 91 5 New Headers 16 92 5.1 Ref-Target Request Header 16 93 5.2 Ref-Integrity Request Header 16 94 5.3 Pass-Through Request Header 17 95 5.4 Resource-Type Response Header 17 96 5.5 Ordered Request Header 17 97 5.6 Position Request Header 18 98 6 New Properties 18 99 6.1 reftarget Property 18 100 6.2 refintegrity Property 18 101 6.3 passthrough Property 19 102 6.4 orderingtype Property 19 103 7 New XML Elements 20 104 7.1 reference XML Element 20 105 7.2 weak XML Element 20 106 7.3 arbitrary XML Element 20 107 7.4 order XML Element 20 108 7.5 member XML Element 20 109 7.6 position XML Element 21 110 7.7 first XML Element 21 111 7.8 last XML Element 21 112 7.9 before XML Element 21 113 7.10 after XML Element 22 114 8 Compliance 22 115 8.1 Class 3 22 116 8.2 Class 4 22 117 9 Dependencies on Other Specifications 22 118 10 Security Considerations 22 119 10.1 Redirect Loops 23 120 10.2 References and Denial of Service 23 121 10.3 Malicious Modifications of Ordering 23 122 10.4 Denial of Service and DAV:orderingtype 23 123 11 Internationalization Considerations 23 124 12 IANA Considerations 24 125 13 Copyright 24 126 14 Intellectual Property 24 127 15 Acknowledgements 24 128 16 References 24 129 17 Authors' Addresses 25 131 1 Terminology 133 The terminology used here follows and extends that in the base 134 WebDAV protocol specification [WebDAV]. 136 Collection 137 A resource that contains member resources 139 Member Resource 140 A resource contained by a collection 142 Referential Resource (or Reference) 143 A resource that has no content of its own, but rather is 144 a reference to another resource 146 Ordinary Resource 147 A member resource that is not a reference to another resource 149 Target Resource 150 The resource referenced by a referential member of a collection 152 Direct Reference 153 A reference that has the property that operations on it are 154 passed through to its target 156 Indirect Reference 157 A reference that has the property that operations on it do 158 not affect its target 160 Strong Reference 161 A reference whose referential integrity is guaranteed by the 162 server 164 Weak Reference 165 A reference whose referential integrity is not guaranteed by the 166 server 168 Referential Integrity 169 A server guarantees the integrity of a reference if it ensures 170 that the reference will not be broken, or enables the 171 reference's owner to ensure that the reference will not be 172 broken. 174 2 Introduction 176 The simple collections that the base WebDAV specification supports 177 are powerful enough to be widely useful. They provide for the 178 hierarchical organization of resources, with mechanisms for 179 creating and deleting collections, copying and moving them, 180 locking them, adding resources to them and deleting resources from 181 them, and getting listings of their members. Delete, copy, move, 182 list, and lock operations can be applied recursively, so that a 183 client can operate on whole hierarchies with a single request. 185 Many applications, however, need more powerful collections. There 186 are two areas in particular where more powerful functionality is 187 often needed: referential resources and ordering. 189 Referential resources make it possible for many collections, on the 190 same or different servers, to share the same resource. Because 191 the collections share the resource by referencing it, only one 192 physical copy of the resource need exist, and any changes made in 193 the resource are visible from all the collections that reference 194 it. 196 It is useful for many applications to be able to impose an 197 ordering on a collection. Orderings may be based on property 198 values, but they may be completely independent of any properties 199 on the collection's member resources. Orderings based on 200 properties can be obtained using a search protocol [DASL], but 201 orderings not based on properties need some other mechanism. 203 Since these two areas are independent of each other, servers may 204 elect to comply with the Referential Resources section of this 205 specification or with the Ordered Collections section or both. 206 A server MUST advertise its compliance through its response to 207 an OPTIONS request, as specified in [WebDAV]. New values for the 208 DAV header are defined in Section 8 below to support this 209 requirement. 211 3 Referential Resources 213 3.1 Scope 215 [WebDAVReq] distinguishes between "weak" references and "strong" 216 references, and also between "indirect" references and "direct" 217 references. This specification supports only weak references and 218 indirect references, but is designed so that it can be extended 219 to support strong references and direct references in the future. 221 Strong references are references whose integrity is guaranteed by 222 the server; weak references are those whose integrity is not 223 guaranteed. Strong references and weak references are both useful 224 in different contexts. Some applications cannot tolerate broken 225 links. A software development application, for example, must be 226 able to rely on the integrity of references to component modules. 227 Such applications must be able to request strong references. Other 228 applications may want to reference target resources on multiple 229 servers, where referential integrity cannot be guaranteed, and may 230 be less concerned about possible broken references. 232 Several considerations led to the decision not to support strong 233 references in the current specification. First, there are many 234 possible policies that applications and services might use to 235 enforce referential integrity. 237 o Delete strong references when their targets are deleted. 239 o Decline to delete targets of strong references. 241 o Notify strong references when their targets have been 242 deleted. 244 o Let owners of resources decide whether strong references to 245 them are allowed. 247 There appears to be no common practice in this area. Moreover, 248 some of the policies have significant security risks. 250 o Moving a target of strong references could be a security 251 risk to the owner of the target by revealing secret 252 locations on the target's server. 254 o A strong reference could be a security risk to the owner of 255 the reference by revealing secret locations on his server. 257 o The presence of strong references to resources on a server 258 could make it impossible to reclaim space on that server 259 by moving or deleting those target resources. 261 These considerations together led to the decision not to support 262 strong references in the short term. 264 Operations on indirect references do not affect their target 265 resources, whereas operations on direct references are passed 266 through to their targets. Both indirect and direct references may 267 be useful. Each of these types of references is implemented in 268 existing systems. Existing HTTP servers are capable of supporting 269 both types of references. In effect, indirect references give 270 clients access to the reference itself, and allow the reference to 271 bear properties. Direct references, once created, simplify access 272 to the target resource by hiding from clients the fact that there 273 is a reference mediating between the client and the target 274 resource. They also make access to the target more efficient, 275 eliminating a round trip required by indirect references to get the 276 URI of the target resource. 278 Again, it was believed that supporting direct references would be 279 too difficult in the short term. Although convenient, they add no 280 functionality beyond what is available through indirect references. 281 Existing systems often implement hybrids of direct and indirect 282 references, for which some operations are passed through to the 283 target while others are not. This fact muddies the issue of what 284 exactly WebDAV should support. It also suggests that the 285 definition of direct references as those for which operations are 286 passed through to their targets may not really capture a class of 287 references that are useful. [what else?] 289 Consequently, it was decided not to support direct references in 290 the short term. 292 3.2 Overview 294 A referential resource is a resource that has no content of its 295 own, but instead references another resource. The resource it 296 references may be in the same collection or anywhere else. This 297 target resource may be a collection or a simple resource or another 298 reference, or any other sort of resource that may be defined in the 299 future. A resource may be the target of any number of referential 300 resources. 302 Since a referential resource is a resource, it can have properties 303 just like any other resource. These properties are completely 304 independent of the properties on its target resource. A new 305 DAV:reftarget property of referential resources has as its value 306 the URI of the target resource. 308 To make it possible to distinguish referential resources from 309 ordinary resources, a new value of the DAV:resourcetype property 310 is defined here. The DAV:resourcetype property of all referential 311 resources MUST have the value reference. 313 Although only weak, indirect references are currently supported, 314 two new DAV properties are defined in anticipation of future 315 support for strong references and direct references. These 316 properties, DAV:refintegrity and DAV:passthrough, will allow 317 clients to distinguish between weak and strong references, and 318 between indirect and direct references. All referential resources 319 MUST have these properties. Although the only value currently 320 defined for DAV:refintegrity is weak, other values may be defined 321 in the future. Although the only value currently defined for 322 DAV:passthrough is none, other values may be defined in the future. 324 3.3 Creating Referential Resources 326 3.3.1 The MKREF Method 328 Referential resources are created using the MKREF method. The 329 request-URI of the MKREF request identifies the resource to be 330 created. The required Ref-Target header contains the URI of the 331 target resource. 333 An optional Ref-Integrity request header is defined below, 334 primarily for future support for strong references. The only value 335 currently defined for this header is "DAV:weak",although other 336 values may be used by private agreement. "DAV:weak" is the default 337 value if the header is not present. 339 An optional Pass-Through request header is defined below, primarily 340 for future support for direct references. Currently, its value is 341 always empty, although other values may be used by private 342 agreement. The default value is empty if the header is not 343 present. 345 An optional Position request header supports ordered collections by 346 allowing the client to specify where the new referential member is 347 to be placed in the collection's ordering. (This header can also 348 be used with PUT to create an ordinary collection member at a 349 specific position in the ordering.) 351 When a server processes a MKREF request, it MUST set the 352 DAV:resourcetype property (defined in [WebDAV]) of the new resource 353 to be DAV:reference. 355 When a server processes a MKREF request, it MUST set the 356 DAV:reftarget property to the URI of the target resource. 358 When a server processes a MKREF request, it MUST set the 359 DAV:refintegrity property and the DAV:passthrough property. 361 The client MUST NOT send any content with the MKREF request, and so 362 MUST NOT use the Content-Length or Transfer-Encoding headers. (See 363 [HTTP].) 365 If a MKREF request is submitted for an existing resource, the 366 existing resource's content and headers will be overwritten. This 367 behavior is analogous to the behavior of the HTTP PUT method. Live 368 properties may get new values at the server's discretion; dead 369 properties will retain their existing values. If the Position 370 header is absent in this case and the collection is ordered, the 371 server MUST leave the member at its previous position in the 372 collection ordering. If the Position header is present and the 373 collection is ordered, the server MUST remove it from its previous 374 position, and then insert it at the requested position. 376 3.3.2 Status Codes 378 201 Created 379 200 OK: modified an existing resource 380 409 Conflict: no resource at Ref-Target 381 unrecognized / unsupported value for Ref-Integrity 382 unrecognized / unsupported value for Pass-Through 383 400 Bad Request: content not allowed 384 409 Conflict: Position Before / After a URI that is not in this 385 collection 386 400 Bad Request: Position Before / After self 387 409 Conflict: Position header, but not an ordered collection 388 425 Insufficient Space on Resource 389 409 Conflict: Parent collection does not exist 391 3.3.3 Example 393 Request: 395 MKREF /~whitehead/dav/spec08.ref HTTP/1.1 396 HOST: www.ics.uci.edu 397 Ref-Target: 399 Response: 401 HTTP/1.1 201 Created 403 This request resulted in the creation of a new referential resource 404 at www.ics.uci.edu/~whitehead/dav/spec08.ref, which points to the 405 resource identified by the Ref-Target header. Its DAV:resourcetype 406 property is set to DAV:reference. Its DAV:reftarget property is 407 set to the URI of its target resource. Its DAV:refintegrity 408 property is set to the default value of DAV:weak. Its 409 DAV:passthrough property is set to the default value of EMPTY. 411 3.4 Deleting Referential Resources 413 3.4.1 The DELREF Method 415 The new DELREF method is used to delete referential resources. 416 DELREF on a referential resource has no effect on its target 417 resource. 419 3.4.2 Status Codes 421 200 OK 422 405 Method Not Allowed: Request-URI is not a reference 423 404 Not Found: No resource at Request-URI 425 3.4.3 Example 427 Request: 429 DELREF /~whitehead/dav/spec08.ref HTTP/1.1 430 HOST: www.ics.uci.edu 432 Response: 434 HTTP/1.1 200 OK 436 The referential resource /~whitehead/dav/spec08.ref has been 437 deleted, but its target resource still exists. 439 3.4.4 Design Rationale 441 The HTTP DELETE method can be used to delete indirect references, 442 since by definition these references do not pass operations through 443 to their targets. 445 If direct references are supported in the future, however, a method 446 distinct from the HTTP DELETE method will be needed for deleting 447 the reference itself. Since direct references do pass operations 448 through to their targets, DELETE would delete the target resource 449 rather than the reference itself. 451 DELREF is being introduced now in anticipation of future needs, 452 and can be used in all cases where a reference is to be deleted. 454 3.5 Listing Referential Members of a Collection 456 Since a referential member of a collection is just a resource in 457 the collection, a listing of members of the collection shows 458 referential members along with ordinary members. That is, a WebDAV 459 PROPFIND request on a collection resource with Depth = 1 or 460 infinity MUST return a response XML element for each ordinary 461 member and for each referential member. 463 If Depth = infinity in the PROPFIND request, the server MUST NOT 464 follow indirect references into any collections to which they may 465 refer. 467 3.6 Other WebDAV Operations on Indirect Referential Resources 469 By definition, operations on an indirect reference affect only the 470 reference, and not its target resource. Since only indirect 471 references are supported by this specification, WebDAV operations 472 that are applied to them affect only the referential resource, not 473 its target resource. 475 A LOCK operation on an indirect reference locks the referential 476 resource, not its target. A LOCK on the collection with 477 Depth = 1 or infinity locks the referential members along with all 478 the other members of the collection, but not the targets of the 479 indirect referential members. 481 A PROPPATCH on an indirect referential resource modifies the 482 properties of the referential resource, not the properties of its 483 target resource. 485 A PROPFIND on an indirect referential resource returns the 486 properties of the referential resource, not the properties of its 487 target resource. 489 A MOVE operation on an indirect referential resource moves the 490 referential resource to a different location, but has no effect on 491 the location of its target. The DAV:reftarget property is unchanged 492 after a MOVE unless the Ref-Target header is used to change it. 494 A COPY operation on an indirect referential resource copies the 495 referential resource, not its target resource, to another location. 496 The DAV:reftarget property of the destination resource is the same 497 as the DAV:reftarget of the source resource, unless the Ref-Target 498 header is used to change it. 500 3.7 HTTP Operations on Indirect Referential Resources 502 Although existing HTTP clients cannot create referential resources, 503 they should be able to read collections created by Class 3 WebDAV 504 clients. They should be able to follow any references in those 505 collections to their targets. To make this possible, a server that 506 receives a GET or HEAD on an indirect reference MUST return a 302 507 (Moved Temporarily) status code. The server MUST follow [HTTP] 508 Section 10.3.3 "302 Moved Temporarily," but with these additional 509 rules: 511 o The Location header MUST contain the target URI of the 512 reference. 514 o The response MUST include a Resource-Type header with the 515 value "Reference". This header allows Class 3 WebDAV clients 516 to recognize the resource as a reference and understand the 517 reason for the redirection. 519 o The response MUST also include those HTTP headers that make 520 sense for referential resources, at a minimum: Cache-Control, 521 Age, ETag, Expires, and Last-Modified. 523 POST cannot be applied to an indirect reference. A reference 524 cannot accept another entity as its subordinate. Depending upon 525 the nature of the target resource, however, it might make sense to 526 apply POST to the target. A server that receives a POST request 527 on an indirect reference MUST return a 302 (Moved Temporarily). 528 The rules for constructing and using the response are the same as 529 for GET and HEAD, except that there is no requirement to return 530 Cache-Control, Age, ETag, Expires, or Last-Modified. 532 PUT cannot be applied to an indirect reference. To replace one 533 indirect reference with another, MKREF MUST be used. To replace an 534 indirect reference with an ordinary resource, the reference MUST 535 first be deleted with DELREF, after which a PUT MUST be used to 536 create the ordinary resource. 538 Existing HTTP clients that do not understand referential resources 539 need to be accommodated, however. To enable these clients to 540 operate reasonably on indirect references, a server that receives a 541 PUT request on an indirect reference MUST return a 302 (Moved 542 Temporarily). The client and server MUST follow [HTTP] Section 543 10.3.3 "302 Moved Temporarily," but with these additional rules: 545 o The Location response header MUST contain the target URI of 546 the reference. 548 o The response MUST include a Resource-Type header, defined in 549 Section 5.n below, with the value "Reference". This header 550 allows Class 3 WebDAV clients to recognize the resource as a 551 reference and understand the reason for the redirection. 553 o The response MUST include an entity body for display to users. 554 The entity body explains that the requested resource is a 555 reference to another resource, and allows the user to choose 556 whether to replace the target resource or to replace the 557 reference. 559 This last rule is needed for PUT, but not for GET, HEAD, or 560 POST. Only for PUT does it make sense for the user to confirm 561 that the operation is to be performed at the request-URI. GET or 562 HEAD will already have returned all useful information about the 563 request-URI. POST makes no sense for the indirect reference at the 564 request-URI. But the user might really want to replace the 565 indirect reference with the entity in the PUT request. 567 Although the new DELREF method has been defined for deleting 568 references, DELETE can be used to delete an indirect reference. 569 Since by definition operations on an indirect reference affect the 570 reference, and not its target, DELETE will delete the indirect 571 reference and leave its target untouched. 573 3.8 Operations on Targets of Referential Resources 575 Operations on targets of weak, indirect referential resources have 576 no effect on the referential resource. 578 4 Ordered Collections 580 4.1 Overview 582 Collections on a compliant server may be ordered, but need not be. 583 It is up to the client to decide whether a given collection is 584 ordered and, if so, to specify the semantics to be used for 585 ordering its members. If a collection is ordered, each of its 586 members must be in the ordering exactly once, and the ordering must 587 not include any resource that is not a member of the collection. 588 Only one ordering can be attached to any collection. Multiple 589 orderings of the same resources can be achieved by creating 590 multiple collections referencing those resources, and attaching a 591 different ordering to each collection. 593 The server is responsible for enforcing these constraints on 594 orderings. The server MUST remove a resource from the ordering 595 when it is removed from the collection. The server MUST add a 596 resource to the ordering when it is added to the collection. 598 When responding to a PROPFIND on a collection, the server MUST 599 order the response elements according to the ordering defined 600 on the collection. 602 4.2 Creating an Ordered Collection 604 4.2.1 Overview 606 When a collection is created, the client can request that it be 607 ordered and specify the semantics of the ordering by using the 608 new Ordered header in the MKCOL request, setting its value to the 609 URI of the semantics to be used. If the client does not want the 610 collection to be ordered, it may omit the Ordered header, or use 611 it with the value "DAV:arbitrary". 613 Every collection MUST have the new DAV:orderingtype property, 614 which indicates whether the collection is ordered and, if so, 615 identifies the semantics of the ordering. A value of DAV:arbitrary 616 indicates that that collection is not ordered. That is, the client 617 cannot depend on the repeatability of the ordering of results from 618 a PROPFIND request. Otherwise the value of DAV:orderingtype is an 619 href that SHOULD point to a resource that contains a definition of 620 the semantics of the ordering, allowing a human user or software 621 package to insert new collection members into the ordering 622 intelligently. 624 If the Ordered header is present on a MKCOL request, the server 625 MUST set the collection's DAV:orderingtype property to the value of 626 the Ordered header. If the Ordered header is not present, the 627 server MUST treat the request as if it had an Ordered header with 628 the value "DAV:arbitrary", meaning that the collection is not 629 ordered. If the collection is ordered, the server MUST respond to 630 PROPFIND requests on the collection using the specified ordering. 632 4.2.2 Status Codes 634 No new error conditions are introduced. 636 4.2.3 Example 638 Request: 640 MKCOL /theNorth/ HTTP/1.1 641 Host: www.server.org 642 Ordered: 644 Response: 646 HTTP/1.1 201 Created 648 In this example, a new, ordered collection was created. Its 649 DAV:orderingtype property has as its value the URI from the 650 Ordered header. In this case, the URI points to a description of 651 the semantics governing the ordering. As new members are added to 652 the collection, clients or end users can consult the semantics to 653 determine how to position the new members in the ordering. 655 4.3 Setting the Position of a Collection Member 657 4.3.1 Overview 659 When a new member is added to a collection with MKREF, PUT, COPY, 660 or MOVE, its position in the ordering can be set with the new 661 Position header. The Position header allows the client to specify 662 that the member should be first in the collection's ordering, last 663 in the collection's ordering, before some other collection member 664 in the collection's ordering, or after some other collection member 665 in the collection's ordering. 667 The server MUST insert the new member into the ordering at the 668 location specified in the Position header, if one is present (and 669 if the collection is ordered); otherwise, it MUST append the new 670 member to the end of the ordering (if the collection is ordered). 671 If a PUT or MKREF causes an existing resource to be replaced, and 672 if the Position header is absent, the server MUST leave the member 673 at its previous position in the collection ordering. If the 674 Position header is present, the server MUST remove the member from 675 its previous position, and then insert it at the requested 676 position. 678 4.3.2 Status Codes 680 201 Created 681 409 Conflict: Before / After a URI that is not in this collection 682 400 Bad Request: Before / After self 683 405 Method Not Allowed: Not an ordered collection 685 4.3.3 Examples 687 Request: 689 MKREF /~whitehead/dav/spec08.ref HTTP/1.1 690 HOST: www.ics.uci.edu 691 Ref-Target: 692 Position: After 694 Response: 696 HTTP/1.1 201 Created 698 This request resulted in the creation of a new referential resource 699 at www.ics.uci.edu/~whitehead/dav/spec08.ref, which points to the 700 resource identified by the Ref-Target header. The Position header 701 in this example caused the server to set its position in the 702 ordering of the /~whitehead/dav/ collection immediately after the 703 requirements.html resource. 705 Request: 707 MOVE /i-d/draft-webdav-protocol-08.txt HTTP/1.1 708 Host: www.ics.uci.edu 709 Destination: 710 Position: First 712 Response: 714 HTTP/1.1 409 Conflict 716 In this case, the server returned a 409 Conflict status code 717 because the /~whitehead/dav/ collection is an unordered collection. 719 Consequently, the server was unable to satisfy the Position 720 header. 722 4.4 Changing the Semantics of a Collection Ordering 724 After a collection has been created, a client can change its 725 ordering semantics, or change an ordered collection to an unordered 726 collection or vice versa, by using PROPPATCH to change the value of 727 its DAV:orderingtype property. The client is then responsible for 728 updating the ordering of the collection members according to the 729 new semantics. PROPPATCH is defined in [WebDAV], Section 7.2. 731 4.5 Changing the Position of a Collection Member 733 4.5.1 The ORDERPATCH Method 735 To change the position of a collection member in the collection's 736 ordering, the client MUST use an ORDERPATCH request with a request 737 body containing an order XML element. The request-URI of an 738 ORDERPATCH request is the URI of the collection whose ordering is 739 to be updated. The order XML element identifies the member 740 resource whose position is to be changed, and describes its new 741 position in the ordering. The new position can be specified as 742 first in the ordering, last in the ordering, before some other 743 collection member in the ordering, or after some other collection 744 member in the ordering. 746 4.5.2 Status Codes 748 Although the protocol currently allows only a single change to be 749 requested with ORDERPATCH, it is anticipated that this may change 750 in the future. Consequently, the server MUST return a 207 751 Multi-Status response, as defined in [WebDAV]. 753 Within the 207 Multi-Status response, the following status codes 754 are possible: 756 200 OK 757 409 Conflict: Before / After a URI that is not in this collection 758 409 Conflict: href doesn't point to a member of this collection 759 400 Bad Request: only one change allowed 760 400 Bad Request: Before / After self 761 405 Method Not Allowed: Not an ordered collection 762 405 Method Not Allowed: Not a collection 763 (It's ok to reposition to the same position) 765 4.5.3 Example 767 Consider a collection /coll-1/ with members ordered as follows: 769 nunavut.map 770 nunavut.img 771 baffin.map 772 baffin.desc 773 baffin.img 774 iqaluit.map 775 nunavut.desc 776 iqaluit.desc 777 iqaluit.img 779 Request: 781 ORDERPATCH /coll-1/ HTTP/1.1 782 Host: www.nunanet.com 783 Content-Type: text/xml 784 Content-Length: xxx 786 787 788 789 790 nunavut.desc 791 792 793 nunavut.map 794 795 796 797 799 Response: 801 HTTP/1.1 207 Multi-Status 802 Content-Type: text/xml 803 Content-Length: xxx 805 806 807 808 809 http://www.nunanet.com/coll-1/nunavut.desc 810 HTTP/1.1 200 OK 811 812 814 In this example, after the request has been processed, the 815 map of nunavut is the first member in the collection's ordering: 817 nunavut.map 818 nunavut.desc 819 nunavut.img 820 baffin.map 821 baffin.desc 822 baffin.img 823 iqaluit.map 824 iqaluit.desc 825 iqaluit.img 827 4.5.4 Design Rationale 828 The decision to introduce the new ORDERPATCH method was made after 829 investigating the possibility of using the existing MOVE method 830 with a Position header. The use of MOVE initially looked 831 appealingly simple: 833 MOVE /root/coll-1/foo HTTP/1.1 834 Host: www.somehost.com 835 Destination: 836 Position: First 838 Unfortunately, several features of the semantics of MOVE make it 839 unsuitable for changing the position of a collection member in the 840 collection's ordering. First, [WebDAV] defines MOVE as logically 841 equivalent to a copy followed by a delete of the source resource. 842 This definition makes it impossible to MOVE a resource to a 843 destination URL that is the same as the source URL. The resource 844 would be deleted rather than moved. Second, [WebDAV] states that 845 when moving a resource to a destination where a resource already 846 exists, the Overwrite header must be "T", and in this case the 847 server must DELETE the resource at the destination before 848 performing the MOVE. Again, this makes it impossible to MOVE 849 a resource to the same location. Finally, [WebDAV] states that 850 locks are lost on a MOVE, an outcome that seems undesirable in this 851 case. 853 The decision to allow only a single change to be described in a 854 PROPPATCH request was made in order to accommodate many existing 855 systems that do not allow multiple changes to be requested at once. 856 However, the protocol design is extensible to support multiple 857 requests in the future. 859 In particular, the decision to define a new order XML element for 860 ORDERPATCH was made for the sake of extensibility. Although the 861 current definition of the order XML element allows only a single 862 change in the ordering per ORDERPATCH request, using an XML element 863 keeps open the option of later allowing multiple changes to be 864 described in a single ORDERPATCH request. Similarly, a 865 Multi-Status response is used in order to keep open the option of 866 multiple changes in a single request in the future. 868 5 New Headers 870 5.1 Ref-Target Request Header 872 Ref-Target = "Ref-Target" ":" Coded-url 874 Coded-url is defined in [WebDAV], Section 8.4. 876 The Ref-Target request header is used with the MKREF method to 877 identify the target resource of the new referential resource being 878 created. It is a required header in MKREF requests. This header 879 may also be used with COPY and MOVE requests to change the target 880 of the destination reference. 882 5.2 Ref-Integrity Request Header 883 Ref-Integrity = "Ref-Integrity" ":" ("DAV:weak") 885 The Ref-Integrity header is defined to allow future support for 886 strong references. It specifies whether the server should 887 enforce referential integrity for a referential resource being 888 created with MKREF. The only value currently defined for the 889 Ref-Integrity header is "DAV:weak", which means that the server 890 need not [should not? must not?] enforce referential integrity for 891 the newly created reference. Other values may be used by private 892 agreement between the client and server. If the header is not 893 present on a MKREF request, the server MUST treat the request as 894 if it has a Ref-Integrity header set to "DAV:weak". This header 895 may also be used with COPY and MOVE requests. If this header is 896 not present on a COPY or MOVE request, the DAV:refintegrity 897 property MUST be treated like any other live property, as 898 specified in [WebDAV] sections 7.8.2 and 7.9.1. 900 5.3 Pass-Through Request Header 902 Pass-Through = "Pass-Through" ":" "" 904 The Pass-Through header is defined to allow future support for 905 direct references. Indirect references do not pass operations 906 through to their target resources, so for them the value of 907 the Pass-Through header is empty. Direct references pass all 908 operations through to their target resources. Other types of 909 references may pass certain operations through, while others may 910 affect the reference itself. Since only indirect references are 911 supported today, the only value currently defined for Pass-Through 912 is empty. Other values may be used by private agreement between 913 the client and server. If the header is not present on a MKREF 914 request, the server MUST treat the request as if it has a 915 Pass-Through header with the value empty. This header may also be 916 used with a COPY or MOVE request on a reference. If this header is 917 not present on a COPY or MOVE request, the DAV:passthrough 918 property MUST be treated like any other live property, as 919 specified in [WebDAV] sections 7.8.2 and 7.9.1. 921 5.4 Resource-Type Response Header 923 Resource-Type = "Resource-Type" ":" ["DAV:collection" | 924 "DAV:reference" | ""] 926 The Resource-Type response header contains the value of the 927 DAV:resourcetype property. It is used with 302 responses to PUT, 928 POST, GET, or HEAD requests on referential resources to indicate to 929 the client that the reason for the redirection is that the 930 request-URI pointed to a referential resource. 932 5.5 Ordered Request Header 934 Ordered = "Ordered" ":" ("DAV:arbitrary" | Coded-url) 936 The Ordered request header may be used with MKCOL to request that 937 the new collection be ordered and to specify its ordering 938 semantics. A value of "DAV:arbitrary" indicates that the 939 collection is not ordered. That is, the client cannot depend on 940 the repeatability of the ordering of results from a PROPFIND 941 request. A Coded-url value indicates that the collection is 942 ordered, and identifies the semantics of the ordering. The 943 Coded-url SHOULD point to a resource that contains a definition of 944 the semantics of the ordering, allowing a human user or software 945 package to insert new collection members into the ordering 946 intelligently. 948 If the Ordered header is not present on a MKCOL request, the 949 server MUST treat the request as if it had an Ordered header with 950 the value "DAV:arbitrary". 952 5.6 Position Request Header 954 Position = "Position" ":" ("First" | "Last" | 955 (("Before" | "After") Coded-url)) 957 The Position header may be used with MKREF, PUT, COPY, or MOVE to 958 tell the server where in the collection ordering to position the 959 resource being added to the collection. It may be used for both 960 ordinary and referential members. 962 If the Coded-url is a relative URL, it is interpreted relative to 963 the collection in which the resource is being created. 965 If the Position request header is not used, then: 967 If the request is replacing an existing resource, the server 968 MUST preserve the present ordering. 970 If the request is adding a new member to the collection, the 971 server MUST append the new member to the end of the ordering 972 (if the collection is ordered). 974 6 New Properties 976 6.1 reftarget Property 978 Name: reftarget 979 Namespace: DAV: 980 Purpose: A required property of referential resources that 981 provides an efficient way for clients to discover 982 the URI of the target resource. This is a readonly 983 property, whose value can only be set by using the 984 Ref-Target header with a MKREF, COPY, or MOVE 985 request. 986 Value: URI of the target resource. 988 990 6.2 refintegrity Property 991 Name: refintegrity 992 Namespace: DAV: 993 Purpose: A required property of a referential resource that 994 indicates whether the server guarantees referential 995 integrity for that reference. The refintegrity 996 property is defined to allow future support for 997 strong references. The only value currently 998 defined for refintegrity is weak, which means that 999 the server need not [does not?] enforce referential 1000 integrity for the reference. Other values may be 1001 used by private agreement between the client and 1002 server. This is a readonly property, whose value 1003 can only be set by using the Ref-Integrity header 1004 with a MKREF, COPY, or MOVE request. 1005 Value: weak 1007 1009 6.3 passthrough Property 1011 Name: passthrough 1012 Namespace: DAV 1013 Purpose: A required property of a referential resource that 1014 indicates what operations are passed through to its 1015 target resource. The passthrough property is 1016 defined to allow future support for direct 1017 references, which pass all operations through to 1018 their targets. This specification currently 1019 supports only indirect references, which do not 1020 pass any operations through to their targets. The 1021 only value currently defined for passthrough is 1022 EMPTY. Other values may be used by private 1023 agreement between the client and server. This is 1024 a read-only property, whose value can only be set 1025 by using the Pass-Through header with a MKREF, 1026 COPY, or MOVE request. 1027 Value: EMPTY 1029 1031 6.4 orderingtype Property 1033 Name: orderingtype 1034 Namespace: DAV: 1035 Purpose: Indicates whether the collection is ordered and, if 1036 so, uniquely identifies the semantics of the 1037 ordering being used. SHOULD also provide an 1038 explanation of the semantics in human and / or 1039 machine-readable form. At a minimum, this allows 1040 human users who add members to the collection to 1041 understand where to position them in the ordering. 1042 Value: arbitrary for an unordered collection, or a URI 1043 that uniquely identifies the semantics of the 1044 collection's ordering. The URI SHOULD point to 1045 a definition of the ordering semantics. 1047 1049 7 New XML Elements 1051 7.1 reference XML Element 1053 Name: reference 1054 Namespace: DAV: 1055 Purpose: A new value of the DAV:resourcetype property that 1056 identifies its resource as a referential resource. 1057 The DAV:resourcetype property of a referential 1058 resource MUST have this value. 1059 Value: EMPTY 1061 1063 7.2 weak XML Element 1065 Name: weak 1066 Namespace: DAV: 1067 Purpose: The only value currently defined for the 1068 DAV:refintegrity property. It means that the 1069 server need not [does not?] enforce referential 1070 integrity for the reference to which the property 1071 belongs. 1072 Value: EMPTY 1074 1076 7.3 arbitrary XML Element 1078 Name: arbitrary 1079 Namespace: DAV: 1080 Purpose: A value of the DAV:orderingtype property that 1081 indicates that the collection is not ordered. That 1082 is, the client cannot depend on the repeatability 1083 of the ordering of results from a PROPFIND request. 1084 Value: EMPTY 1086 1088 7.4 order XML Element 1090 Name: order 1091 Namespace: DAV 1092 Purpose: For use with the new ORDERPATCH method. Describes 1093 a change to be made in a collection ordering. 1094 Value: A description of the new position of a collection 1095 member in the collection's ordering. 1097 1099 7.5 member XML Element 1100 Name: member 1101 Namespace: DAV 1102 Purpose: Occurs in the order XML Element, and describes the 1103 new position of a single collection member in the 1104 collection's ordering. 1105 Value: An href containing the relative URI of the 1106 collection member, and a description of its new 1107 position in the ordering. The href XML element is 1108 defined in [WebDAV], Section 11.3. 1110 1112 7.6 position XML Element 1114 Name: position 1115 Namespace: DAV 1116 Purpose: Occurs in the member XML element. Describes the 1117 new position in a collection's ordering of one of 1118 the collection's members. 1119 Value: The new position can be described as first in the 1120 collection's ordering, last in the collection's 1121 ordering, before some other member of the 1122 collection, or after some other member of the 1123 collection. 1125 1127 7.7 first XML Element 1129 Name: first 1130 Namespace: DAV 1131 Purpose: Occurs in the position XML element. Describes the 1132 collection member's position as first in the 1133 collection's ordering. 1134 Value: EMPTY 1136 1138 7.8 last XML Element 1140 Name: last 1141 Namespace: DAV 1142 Purpose: Occurs in the position XML element. Describes the 1143 collection member's position as last in the 1144 collection's ordering. 1145 Value: EMPTY 1147 1149 7.9 before XML Element 1151 Name: before 1152 Namespace: DAV 1153 Purpose: Occurs in the position XML element. Describes the 1154 collection member's position as coming before some 1155 other collection member in the collection's 1156 ordering. 1157 Value: href of the member it precedes in the ordering 1159 1161 7.10 after XML Element 1163 Name: after 1164 Namespace: DAV 1165 Purpose: Occurs in the position XML element. Describes the 1166 collection member's position as coming after some 1167 other collection member in the collection's 1168 ordering. 1169 Value: href of the member it follows in the ordering 1171 1173 8 Compliance 1175 Section 14 of [Goland et al, 1998] defined a DAV header for use 1176 when responding to OPTIONS requests. This header provides a way 1177 for clients to discover which parts of WebDAV a resource supports. 1178 The WebDAV specifications define numbered compliance classes 1179 corresponding to collections of related functions that resources 1180 may support. When the server receives an OPTIONS request, it lists 1181 the classes that the request-URI supports in the DAV response 1182 header. 1184 Since this specification defines two independent sets of 1185 functionality, it defines two new compliance classes. A WebDAV 1186 server may support neither, one or the other, or both for any 1187 resource. 1189 8.1 Class 3 1191 This new compliance class indicates compliance with Section 3 1192 "Referential Resources" of this specification. Servers that comply 1193 with Section 3 MUST list this class in the DAV response header 1194 when they respond to an OPTIONS request. 1196 8.2 Class 4 1198 This new compliance class indicates compliance with Section 4 1199 "Ordered Collections" of this specification. Servers that comply 1200 with Section 4 MUST list this class in the DAV response header 1201 when they respond to an OPTIONS request. 1203 9 Dependencies on Other Specifications 1205 TBD 1207 10 Security Considerations 1209 This section is provided to detail issues concerning security 1210 implications of which WebDAV applications need to be aware. 1212 All of the security considerations of HTTP/1.1 and the base WebDAV 1213 protocol also apply to WebDAV collections. In addition, 1214 referential resources and ordered collections introduce several 1215 new security concerns and increase the risk of some existing 1216 threats. These issues are detailed below. 1218 10.1 Redirect Loops 1220 Although redirect loops were already possible in HTTP 1.1, the 1221 introduction of referential resources creates a new avenue for 1222 clients to create loops accidentally or maliciously. If the 1223 referential resource and its target are on the same server, the 1224 server may be able to detect MKREF requests that would create 1225 loops. See also [HTTP], Section 10.3 "Redirection 3xx." 1227 10.2 References and Denial of Service 1229 The introduction of referential resources creates a new avenue 1230 for denial of service attacks. Clients can create heavily used 1231 references to target locations that were not designed for heavy 1232 usage. 1234 10.3 Malicious Modifications of Ordering 1236 Particularly in large collections, moving a collection member to 1237 a different position in the ordering can make it very difficult 1238 for users to find. 1240 10.4 Denial of Service and DAV:orderingtype 1242 There may be some risk of denial of service at sites that are 1243 advertised in the DAV:orderingtype property of collections. 1244 However, it is anticipated that widely-deployed applications will 1245 use hard-coded values for frequently-used ordering semantics 1246 rather than looking up the semantics at the location specified by 1247 DAV:orderingtype. 1249 11 Internationalization Considerations 1251 This specification follows the practices of [WebDAV] in encoding 1252 all human-readable content using XML [XML] and in the treatment 1253 of names. Consequently, this specification complies with the 1254 IETF Character Set Policy [Alvestrand]. 1256 WebDAV applications MUST support the character set tagging, 1257 character set encoding, and the language tagging functionality of 1258 the XML specification. This constraint ensures that the human- 1259 readable content of this specification complies with [Alvestrand]. 1261 As in [WebDAV}, names in this specification fall into three 1262 categories: names of protocol elements such as methods and 1263 headers, names of XML elements, and names of properties. Naming 1264 of protocol elements follows the precedent of HTTP, using English 1265 names encoded in USASCII for methods and headers. The names of 1266 XML elements used in this specification are English names encoded 1267 in UTF-8. 1269 For error reporting, [WebDAV] follows the convention of HTTP/1.1 1270 status codes, including with each status code a short, English 1271 description of the code (e.g., 423 Locked). Internationalized 1272 applications will ignore this message, and display an appropriate 1273 message in the user's language and character set. 1275 For rationales for these decisions and advice for application 1276 implementors, see [WebDAV]. 1278 12 IANA Considerations 1280 TBD 1282 13 Copyright 1284 14 Intellectual Property 1286 15 Acknowledgements 1288 This draft has benefited from thoughtful discussion by 1289 Steve Carter, Ellis Cohen, Spencer Dawkins, Rajiv Dulepet, 1290 Chuck Fay, Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann, 1291 Marcus Jager, Rohit Khare, Daniel LaLiberte, Steve Martin, 1292 Surendra Koduru Reddy, Sam Ruby, Bradley Sergeant, Nick Shelness, 1293 John Stracke, John Tigue, John Turner, and others. 1295 16 References 1297 [WebDAV] Y. Y. Goland, E. J. Whitehead, Jr., A. 1298 Faizi, S. R. Carter, D. Jensen, "Extensions for Distributed 1299 Authoring on the World Wide Web - WebDAV." Draft-ietf-webdav- 1300 protocol-08. Internet Draft, work in progress. Microsoft, 1301 U.C. Irvine, Netscape, Novell. April, 1998. 1303 [DASL] Saveen Reddy, D. Jensen, Surendra Reddy, 1304 R. Henderson, J. Davis, A. Babich, "DAV Searching & Locating." 1305 Draft-reddy-dasl-protocol-02. Internet Draft, work in progress. 1306 Microsoft, Novell, Oracle, Netscape, Xerox, Filenet. June, 1998. 1308 [WebDAVReq] J. Slein, J. Davis, "Requirements for Advanced 1309 Collection Functionality in WebDAV." Draft-ietf-webdav-collection- 1310 reqts-02. Internet Draft, work in progress. Xerox, 1998. 1312 [HTTP] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, 1313 T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1." 1314 RFC 2068. UC Irvine, DEC, MIT/LCS. January, 1997. 1316 [XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible Markup 1317 Language (XML)." World Wide Web Consortium Recommendation 1318 REC-xml-19980210. http://www.w3.org/TR/1998/REC-xml-19980210. 1320 17 Authors' Addresses 1322 J. Slein 1323 Xerox Corporation 1324 800 Phillips Road, 105-50C 1325 Webster, NY 14580 1326 Email: slein@wrc.xerox.com 1328 J. Davis 1329 Xerox Corporation 1330 3333 Coyote Hill Road 1331 Palo Alto, CA 94304 1332 Email: jdavis@parc.xerox.com 1334 A. Babich 1335 FileNet Corporation 1336 3565 Harbor Boulevard 1337 Costa Mesa, CA 92626-1420 1338 Email: ababich@filenet.com 1340 E.J. Whitehead Jr. 1341 Dept. of Information and Computer Science 1342 University of California, Irvine 1343 Irvine, CA 92697-3425 1344 Email: ejw@ics.uci.edu 1346 Expires January 31, 1999