idnits 2.17.1 draft-reschke-http-oob-encoding-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 17, 2016) is 2960 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 5988 (Obsoleted by RFC 8288) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) == Outdated reference: A later version (-09) exists of draft-ietf-httpbis-encryption-encoding-00 == Outdated reference: A later version (-03) exists of draft-thomson-http-mice-00 -- Obsolete informational reference (is this intentional?): RFC 7232 (Obsoleted by RFC 9110) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Reschke 3 Internet-Draft greenbytes 4 Intended status: Standards Track S. Loreto 5 Expires: September 18, 2016 Ericsson 6 March 17, 2016 8 'Out-Of-Band' Content Coding for HTTP 9 draft-reschke-http-oob-encoding-04 11 Abstract 13 This document describes an Hypertext Transfer Protocol (HTTP) content 14 coding that can be used to describe the location of a secondary 15 resource that contains the payload. 17 Editorial Note (To be removed by RFC Editor before publication) 19 Distribution of this document is unlimited. Although this is not a 20 work item of the HTTPbis Working Group, comments should be sent to 21 the Hypertext Transfer Protocol (HTTP) mailing list at 22 ietf-http-wg@w3.org [1], which may be joined by sending a message 23 with subject "subscribe" to ietf-http-wg-request@w3.org [2]. 25 Discussions of the HTTPbis Working Group are archived at 26 . 28 XML versions, latest edits, and issue tracking for this document are 29 available from and 30 . 32 The changes in this draft are summarized in Appendix C.4. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 18, 2016. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4 69 3. 'Out-Of-Band' Content Coding . . . . . . . . . . . . . . . . . 4 70 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.3. Problem Reporting . . . . . . . . . . . . . . . . . . . . 6 73 3.3.1. Server Not Reachable . . . . . . . . . . . . . . . . . 7 74 3.3.2. Resource Not Found . . . . . . . . . . . . . . . . . . 7 75 3.3.3. Payload Unusable . . . . . . . . . . . . . . . . . . . 7 76 3.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 3.4.1. Basic Example . . . . . . . . . . . . . . . . . . . . 7 78 3.4.2. Example involving an encrypted resource . . . . . . . 9 79 3.4.3. Example For Problem Reporting . . . . . . . . . . . . 10 80 4. Feature Discovery . . . . . . . . . . . . . . . . . . . . . . 10 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 82 5.1. Content Modifications . . . . . . . . . . . . . . . . . . 10 83 5.2. Content Stealing . . . . . . . . . . . . . . . . . . . . . 10 84 5.3. Use in Requests . . . . . . . . . . . . . . . . . . . . . 11 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 86 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 88 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 89 Appendix A. Alternatives, or: why not a new Status Code? . . . . 13 90 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 13 91 B.1. Range Requests . . . . . . . . . . . . . . . . . . . . . . 13 92 B.2. Accessing the Secondary Resource Too Early . . . . . . . . 14 93 B.3. Resource maps . . . . . . . . . . . . . . . . . . . . . . 14 94 B.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 14 95 Appendix C. Change Log (to be removed by RFC Editor before 96 publication) . . . . . . . . . . . . . . . . . . . . 15 97 C.1. Changes since draft-reschke-http-oob-encoding-00 . . . . . 15 98 C.2. Changes since draft-reschke-http-oob-encoding-01 . . . . . 15 99 C.3. Changes since draft-reschke-http-oob-encoding-02 . . . . . 15 100 C.4. Changes since draft-reschke-http-oob-encoding-03 . . . . . 15 101 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 15 103 1. Introduction 105 This document describes an Hypertext Transfer Protocol (HTTP) content 106 coding (Section 3.1.2.1 of [RFC7231]) that can be used to describe 107 the location of a secondary resource that contains the payload. 109 The primary use case for this content coding is to enable origin 110 servers to delegate the delivery of content to a secondary server 111 that might be "closer" to the client (with respect to network 112 topology) and/or able to cache content, leveraging content 113 encryption, as described in [ENCRYPTENC]. 115 2. Notational Conventions 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 This document reuses terminology used in the base HTTP 122 specifications, namely Section 2 of [RFC7230] and Section 3 of 123 [RFC7231]. 125 3. 'Out-Of-Band' Content Coding 127 3.1. Overview 129 The 'Out-Of-Band' content coding is used to direct the recipient to 130 retrieve the actual message representation (Section 3 of [RFC7231]) 131 from a secondary resource, such as a public cache: 133 1. Client performs a request 135 2. Received response specifies the 'out-of-band' content coding; the 136 payload of the response contains additional meta data, plus the 137 location of the secondary resource 139 3. Client performs GET request on secondary resource (usually again 140 via HTTP(s)) 142 4. Secondary server provides payload 144 5. Client combines above representation with additional 145 representation metadata obtained from the primary resource 147 Client Secondary Server Origin Server 149 sends GET request with Accept-Encoding: out-of-band 150 (1) |---------------------------------------------------------\ 151 status 200 and Content-Coding: out-of-band | 152 (2) <---------------------------------------------------------/ 154 GET to secondary server 155 (3) |---------------------------\ 156 payload | 157 (4) <---------------------------/ 159 (5) 160 Client and combines payload received in (4) 161 with metadata received in (2). 163 3.2. Definitions 165 The name of the content coding is "out-of-band". 167 The payload format uses JavaScript Object Notation (JSON, [RFC7159]), 168 describing an object describing secondary resources plus OPTIONAL 169 additional metadata: 171 'URIs' A REQUIRED string array containing at least one URI reference 172 (Section 4.1 of [RFC3986]) of a secondary resource. 174 'fallback' An OPTIONAL string containing a URI reference of a 175 fallback resource (see Appendix B.2). This URI reference, after 176 resolution against the URI of the primary resource, MUST identify 177 a resource on the same server as the primary resource. 179 'metadata' An OPTIONAL object containing additional members, 180 representing header field values which can not appear as header 181 fields in the response message itself (header fields that occur 182 multiple times need to be combined into a single field value as 183 per Section 3.2.2 of [RFC7230]; header field names are lower- 184 cased). 186 The payload format uses a JSON array so that the origin server can 187 specify multiple secondary resources. When a client receives a 188 response containing multiple URIs, it is free to choose which of 189 these to use. 191 New specifications can define new OPTIONAL header fields, thus 192 clients MUST ignore unknown fields. Extension specifications will 193 have to update this specification. [[anchor3: or we define a 194 registry]] 195 The client then obtains the original message by: 197 1. Unwrapping the encapsulated HTTP message by removing any transfer 198 and content codings. 200 2. Replacing/setting any response header fields from the primary 201 response except for framing-related information such as Content- 202 Length, Transfer-Encoding and Content-Encoding. 204 3. Replacing/setting any header fields with those present as members 205 in the "metadata" object. [[anchor4: Do we have a use case for 206 this?]] 208 If the client is unable to retrieve the secondary resource's 209 representation (host can't be reached, non 2xx response status code, 210 payload failing integrity check, etc.), it can choose an alternate 211 secondary resource (if specified), try the fallback URI (if given), 212 or simply retry the request to the origin server without including 213 "out-of-band" in the Accept-Encoding request header field. In the 214 latter case, it can be useful to inform the origin server about what 215 problems were encountered when trying to access the secondary 216 resource; see Section 3.3 for details. 218 Note that although this mechanism causes the inclusion of external 219 content, it will not affect the application-level security properties 220 of the reconstructed message, such as its web origin ([RFC6454]). 222 The cacheability of the response for the secondary resource does not 223 affect the cacheability of the reconstructed response message, which 224 is the same as for the origin server's response. 226 Note that because the server's response depends on the request's 227 Accept-Encoding header field, the response usually will need to be 228 declared to vary on that. See Section 7.1.4 of [RFC7231] and Section 229 2.3 of [RFC7232] for details. 231 3.3. Problem Reporting 233 When the client fails to obtain the secondary resource, it can be 234 useful to inform the origin server about the condition. This can be 235 accomplished by adding a "Link" header field ([RFC5988]) to a 236 subsequent request to the origin server, detailing the URI of the 237 secondary resource and the failure reason. 239 The following link extension relations are defined: 241 3.3.1. Server Not Reachable 243 Used in case the server was not reachable. 245 Link relation: 247 http://purl.org/NET/linkrel/not-reachable 249 3.3.2. Resource Not Found 251 Used in case the server responded, but the object could not be 252 obtained. 254 Link relation: 256 http://purl.org/NET/linkrel/resource-not-found 258 3.3.3. Payload Unusable 260 Used in case the the payload could be obtained, but wasn't usable 261 (for instance, because integrity checks failed). 263 Link relation: 265 http://purl.org/NET/linkrel/payload-unusable 267 3.4. Examples 269 3.4.1. Basic Example 271 Client request of primary resource: 273 GET /test HTTP/1.1 274 Host: www.example.com 275 Accept-Encoding: gzip, out-of-band 277 Response: 279 HTTP/1.1 200 OK 280 Date: Thu, 14 May 2015 18:52:00 GMT 281 Content-Type: text/plain 282 Cache-Control: max-age=10, public 283 Content-Encoding: out-of-band 284 Content-Length: 145 285 Vary: Accept-Encoding 287 { 288 "URIs": [ 289 "http://example.net/bae27c36-fa6a-11e4-ae5d-00059a3c7a00" 290 ], 291 "fallback": "/c/bae27c36-fa6a-11e4-ae5d-00059a3c7a00" 292 } 294 (note that the Content-Type header field describes the media type of 295 the secondary's resource representation, and the origin server 296 supplied a fallback URI) 298 Client request for secondary resource: 300 GET /bae27c36-fa6a-11e4-ae5d-00059a3c7a00 HTTP/1.1 301 Host: example.net 303 Response: 305 HTTP/1.1 200 OK 306 Date: Thu, 14 May 2015 18:52:10 GMT 307 Cache-Control: private 308 Content-Length: 15 310 Hello, world. 312 (Note no Content-Type header field is present here because the 313 secondary server truly does not know the media type of the payload) 315 Final message after recombining header fields: 317 HTTP/1.1 200 OK 318 Date: Thu, 14 May 2015 18:52:00 GMT 319 Content-Length: 15 320 Cache-Control: max-age=10, public 321 Content-Type: text/plain 323 Hello, world. 325 3.4.2. Example involving an encrypted resource 327 Given the example HTTP message from Section 5.4 of [ENCRYPTENC], a 328 primary resource could use the "out-of-band" encoding to specify just 329 the location of the secondary resource plus the contents of the 330 "Crypto-Key" header field needed to decrypt the payload: 332 Response: 334 HTTP/1.1 200 OK 335 Date: Thu, 14 May 2015 18:52:00 GMT 336 Content-Encoding: aesgcm128, out-of-band 337 Content-Type: text/plain 338 Encryption: keyid="a1"; salt="vr0o6Uq3w_KDWeatc27mUg" 339 Crypto-Key: keyid="a1"; aesgcm128="csPJEXBYA5U-Tal9EdJi-w" 340 Content-Length: 87 341 Vary: Accept-Encoding 343 { 344 "URIs": [ 345 "http://example.net/bae27c36-fa6a-11e4-ae5d-00059a3c7a00" 346 ] 347 } 349 (note that the Content-Type header field describes the media type of 350 the secondary's resource representation) 352 Response for secondary resource: 354 HTTP/1.1 200 OK 355 Date: Thu, 14 May 2015 18:52:10 GMT 356 Content-Length: ... 357 Cache-Control: private 359 fuag8ThIRIazSHKUqJ5OduR75UgEUuM76J8UFwadEvg 360 (payload body shown in base64 here) 362 Final message undoing all content codings: 364 HTTP/1.1 200 OK 365 Date: Thu, 14 May 2015 18:52:00 GMT 366 Content-Length: 15 367 Content-Type: text/plain 369 I am the walrus 370 Note: in this case, the ability to undo the "aescgm128" is needed 371 to process the response. If "aescgm128" wasn't listed as 372 acceptable content encoding in the request, the origin server 373 wouldn't be able to use the "out-of-band" mechanism. 375 3.4.3. Example For Problem Reporting 377 Client requests primary resource as in Section 3.4.1, but the attempt 378 to access the secondary resource fails. 380 Response: 382 HTTP/1.1 404 Not Found 383 Date: Thu, 08 September 2015 16:49:00 GMT 384 Content-Type: text/plain 385 Content-Length: 20 387 Resource Not Found 389 Client retries with the origin server and includes Link header field 390 reporting the problem: 392 GET /test HTTP/1.1 393 Host: www.example.com 394 Accept-Encoding: gzip, out-of-band 395 Link: ; 396 rel="http://purl.org/NET/linkrel/resource-not-found" 398 4. Feature Discovery 400 New content codings can be deployed easily, as the client can use the 401 "Accept-Encoding" header field (Section 5.3.4 of [RFC7231]) to signal 402 which content codings are supported. 404 5. Security Considerations 406 5.1. Content Modifications 408 This specification does not define means to verify that the payload 409 obtained from the secondary resource really is what the origin server 410 expects it to be. Content signatures can address this concern (see 411 [CONTENTSIG] and [MICE]). 413 5.2. Content Stealing 415 The Out-Of-Band content coding could be used to circumvent the same- 416 origin policy ([RFC6454], Section 3) of user agents: an attacking 417 site which knows the URI of a secondary resource would use the out- 418 of-band coding to trick the user agent to read the contents of the 419 secondary resource, which then, due to the security properties of 420 out-of-band codings, would be handled as if it originated from the 421 origin's resource. 423 This problem is not yet addressed by this specification. Possible 424 defenses would be to rely on signatures and encryption, or to add an 425 indication to the secondary resource's response that would prevent 426 further processing in responses from "bad" origins (not unlike the 427 "Access-Control-Allow-Origin" header field defined in Section 5.1 of 428 [CORS]). 430 5.3. Use in Requests 432 In general, content codings can be used in both requests and 433 responses. This particular content coding has been designed for 434 responses. When supported in requests, it creates a new attack 435 vector where the receiving server can be tricked into including 436 content that the client might not have access to otherwise (such as 437 HTTP resources behind a firewall). 439 6. IANA Considerations 441 The IANA "HTTP Content Coding Registry", located at 442 , needs to be 443 updated with the registration below: 445 Name: out-of-band 447 Description: Payload needs to be retrieved from a secondary resource 449 Reference: Section 3 of this document 451 7. References 453 7.1. Normative References 455 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 456 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 457 RFC2119, March 1997, 458 . 460 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, 461 "Uniform Resource Identifier (URI): Generic Syntax", 462 STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, 463 . 465 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/ 466 RFC5988, October 2010, 467 . 469 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 470 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, 471 March 2014, . 473 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext 474 Transfer Protocol (HTTP/1.1): Message Syntax and 475 Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, 476 . 478 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext 479 Transfer Protocol (HTTP/1.1): Semantics and Content", 480 RFC 7231, DOI 10.17487/RFC7231, June 2014, 481 . 483 7.2. Informative References 485 [CONTENTSIG] Thomson, M., "Content-Signature Header Field for HTTP", 486 draft-thomson-http-content-signature-00 (work in 487 progress), July 2015. 489 [CORS] van Kesteren, A., "Cross-Origin Resource Sharing", W3C 490 Recommendation REC-cors-20140116, January 2014, 491 . 493 Latest version available at 494 . 496 [ENCRYPTENC] Thomson, M., "Encrypted Content-Encoding for HTTP", 497 draft-ietf-httpbis-encryption-encoding-00 (work in 498 progress), December 2015. 500 [MICE] Thomson, M., "Merkle Integrity Content Encoding", 501 draft-thomson-http-mice-00 (work in progress), 502 January 2016. 504 [RFC2017] Freed, N. and K. Moore, "Definition of the URL MIME 505 External-Body Access-Type", RFC 2017, DOI 10.17487/ 506 RFC2017, October 1996, 507 . 509 [RFC4483] Burger, E., "A Mechanism for Content Indirection in 510 Session Initiation Protocol (SIP) Messages", RFC 4483, 511 DOI 10.17487/RFC4483, May 2006, 512 . 514 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 515 DOI 10.17487/RFC6454, December 2011, 516 . 518 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext 519 Transfer Protocol (HTTP/1.1): Conditional Requests", 520 RFC 7232, DOI 10.17487/RFC7232, June 2014, 521 . 523 URIs 525 [1] 527 [2] 529 Appendix A. Alternatives, or: why not a new Status Code? 531 A plausible alternative approach would be to implement this 532 functionality one level up, using a new redirect status code (Section 533 6.4 of [RFC7231]). However, this would have several drawbacks: 535 o Servers will need to know whether a client understands the new 536 status code; thus some additional signal to opt into this protocol 537 would always be needed. 539 o In redirect messages, representation metadata (Section 3.1 of 540 [RFC7231]), namely "Content-Type", applies to the response 541 message, not the redirected-to resource. 543 o The origin-preserving nature of using a content coding woudld be 544 lost. 546 Another alternative would be to implement the indirection on the 547 level of the media type using something similar to the type "message/ 548 external-body", defined in [RFC2017] and refined for use in the 549 Session Initiation Protocol (SIP) in [RFC4483]. This approach though 550 would share most of the drawbacks of the status code approach 551 mentioned above. 553 Appendix B. Open Issues 555 B.1. Range Requests 557 We probably need to handle Range Requests. How would this work? 558 Passing down the Range request header field to the secondary 559 resource? 561 What about codes other than 200 and 206? 563 B.2. Accessing the Secondary Resource Too Early 565 One use-case for this protocol is to enable a system of "blind 566 caches", which would serve the secondary resources. These caches 567 might only be populated on demand, thus it could happen that whatever 568 mechanism is used to populate the cache hasn't finished when the 569 client hits it (maybe due to race conditions, or because the cache is 570 behind a middlebox which doesn't allow the origin server to push 571 content to it). 573 In this particular case, it can be useful if the client was able to 574 "piggyback" the URI of the fallback for the primary resource, giving 575 the secondary server a means by which it could obtain the payload 576 itself. This information could be provided in yet another Link 577 header field: 579 GET bae27c36-fa6a-11e4-ae5d-00059a3c7a00 HTTP/1.1 580 Host: example.net 581 Link: ; 582 rel="http://purl.org/NET/linkrel/primary-resource" 584 (continuing the example from Section 3.4.1) 586 B.3. Resource maps 588 When out-of-band encoding is used as part of a caching solution, the 589 additional round trips to the origin server can be a significant 590 performance problem; in particular, when many small resources need to 591 be loaded (such as scripts, images, or video fragments). In cases 592 like these, it could be useful for the origin server to provide a 593 "resource map", allowing to skip the round trips to the origin server 594 for these mapped resources. Plausible ways to transmit the resource 595 map could be: 597 o as extension in the out-of-band encoding JSON payload, or 599 o as separate resource identified by a "Link" response header field. 601 This specification does not define a format, nor a mechanism to 602 transport the map, but it's a given that some specification using 603 "out-of-band" encoding will do. 605 B.4. Padding 607 It might be a good idea to allow padding in the secondary resource's 608 payload, in order to even hide the precise content length. This 609 could be accomplished by adding range information to the out-of-band 610 metadata, allowing the client to throw away parts of the payload when 611 reconstructing the response body. 613 Appendix C. Change Log (to be removed by RFC Editor before publication) 615 C.1. Changes since draft-reschke-http-oob-encoding-00 617 Mention media type approach. 619 Explain that clients can always fall back not to use oob when the 620 secondary resource isn't available. 622 Add Vary response header field to examples and mention that it'll 623 usually be needed 624 (). 626 Experimentally add problem reporting using piggy-backed Link header 627 fields (). 629 C.2. Changes since draft-reschke-http-oob-encoding-01 631 Updated ENCRYPTENC reference. 633 C.3. Changes since draft-reschke-http-oob-encoding-02 635 Add MICE reference. 637 Remove the ability of the secondary resource to contain anything but 638 the payload (). 640 Changed JSON payload to be an object containing an array of URIs plus 641 additional members. Specify "fallback" as one of these additional 642 members, and update Appendix B.2 accordingly). 644 Discuss extensibility a bit. 646 C.4. Changes since draft-reschke-http-oob-encoding-03 648 Mention "Content Stealing" thread. 650 Mention padding. 652 Appendix D. Acknowledgements 654 Thanks to Christer Holmberg, Daniel Lindstrom, Goran Eriksson, John 655 Mattsson, Kevin Smith, Magnus Westerlund, Mark Nottingham, Martin 656 Thomson, and Roland Zink for feedback on this document. 658 Authors' Addresses 660 Julian F. Reschke 661 greenbytes GmbH 662 Hafenweg 16 663 Muenster, NW 48155 664 Germany 666 EMail: julian.reschke@greenbytes.de 667 URI: http://greenbytes.de/tech/webdav/ 669 Salvatore Loreto 670 Ericsson 671 Torshamnsgatan 21 672 Stochholm 16483 673 Sweden 675 EMail: salvatore.loreto@ericsson.com