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