idnits 2.17.1 draft-wood-dtnrg-http-dtn-delivery-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (October 25, 2009) is 5296 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-09) exists of draft-irtf-dtnrg-bundle-checksum-06 == Outdated reference: A later version (-08) exists of draft-wood-tae-specifying-uri-transports-07 == Outdated reference: A later version (-22) exists of draft-wood-tsvwg-saratoga-04 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Wood 3 Internet-Draft Surrey 4 Intended status: Experimental P. Holliday 5 Expires: April 28, 2010 Cisco Systems 6 October 25, 2009 8 Using HTTP for delivery in Delay/Disruption-Tolerant Networks 9 draft-wood-dtnrg-http-dtn-delivery-04 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 28, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document describes how to use the Hypertext Transfer Protocol, 48 HTTP, for communication across delay- and disruption-tolerant 49 networks, by making every transit node in the network HTTP-capable, 50 and doing peer HTTP transfers between nodes to move data hop-by-hop 51 or subnet-by-subnet towards its final destination. HTTP is well- 52 known and straightforward to implement in these networks. 54 Table of Contents 56 1. Background and Introduction . . . . . . . . . . . . . . . . . 3 57 2. Adapting the HTTP delivery mechanism for DTNs . . . . . . . . 5 58 3. Other useful proposed additional HTTP headers . . . . . . . . 7 59 4. Other suggestions on using MIME in DTN networks . . . . . . . 8 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 65 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 68 1. Background and Introduction 70 Delay- and Disruption-Tolerant Networks (DTNs) are networks where 71 conditions are such that links between nodes are not always 72 permanent, may be of very long delay or exist only during very short 73 contact periods where the link is up, and may change over time 74 [RFC4838]. Some DTNs can be thought of as sparse ad-hoc networks, 75 with nodes communicating intermittently only when they come into 76 contact. Store-and-forward delivery of data is a useful way of 77 communicating across these networks. 79 A specialised store-and-forward protocol for DTN delivery has been 80 proposed in the IRTF DTN research group (DTNRG) - the Bundle Protocol 81 [RFC5050]. Criticisms of the Bundle Protocol's lack of reliability 82 and its complexity have been made [I-D.irtf-dtnrg-bundle-checksum]. 83 The Bundle Protocol is itself intended to be a routable data format, 84 but the supporting architectures for node and application naming/ 85 addressing, automated routing, security, QoS, and resource discovery 86 have not yet been agreed upon or in some cases even significantly 87 worked on. These things already exist for the Internet Protocol, and 88 can in many cases be easily leveraged for DTN networks [Wood09a]. 90 This document outlines how the well-known Hypertext Transfer Protocol 91 (HTTP) [RFC2616] can be used for store-and-forward communication 92 across DTNs. HTTP is not used end-to-end as it is on the web. 93 Instead, applications running on each node in the network communicate 94 with their neighbours using dedicated hop-by-hop or subnet-by-subnet 95 HTTP transfers to effect local data delivery. Additional HTTP header 96 information adds context for onward forwarding and delivery to 97 destination endpoints, and provides the reliability and support for 98 error-detection currently missing from the alternative Bundle 99 Protocol. 101 It must be stressed that this proposed use is distinct from proxy 102 caching methods prevalent in the traditional web. Caching commands 103 are not used; end-to-end HTTP requests are not intercepted by 104 intermediate caches that attempt to fulfil them in the traditional 105 web caching sense. 107 Although HTTP-DTN use as as a hop-by-hop message carrier between 108 caches implementing some form of routing protocol between them, the 109 distinction between client, server and proxy is replaced by peer 110 intermediate caches using HTTP to communicate in separate sessions 111 that together combine over time to make the full path between 112 original source and final destination for the data. 114 HTTP is a session layer, running over a transport layer providing 115 reliable delivery of the HTTP stream between hops. This transport 116 layer is commonly (and almost universally) TCP in the terrestrial 117 Internet, although alternative transport layers, such as SCTP, can 118 also be used under HTTP [I-D.natarajan-http-over-sctp]. For long- 119 delay networks, or for network conditions where TCP or an equivalent 120 is not suitable, an alternative transport layer such as Saratoga 121 [I-D.wood-tsvwg-saratoga] can be used under HTTP instead in hop-by- 122 hop communications between nodes. HTTP requires only reliable 123 streaming that can be used to provide ordered delivery; how that 124 reliable streaming is provided is up to the local transport layer in 125 the local subnet, and multiple different transport layers can be used 126 across the multiple hops between nodes to transfer data from source 127 to final destination. 129 Steve Deering has often described IP as 'the waist in the hourglass' 130 [Deering98] - what is above and touching on IP can be changed, what 131 is below and touching on IP can be changed, but provided the new 132 elements continue to interface to and work with IP, the hourglass 133 remains complete and the network stack remains functional. Here, 134 HTTP is the waist in this particular hourglass; applications can use 135 HTTP to communicate, provided HTTP runs over a reliable transport 136 stream. The applications can vary. The transport stream can be 137 changed; HTTP does not have to run over TCP/IP, but could even be 138 made to run directly over e.g. HDLC or a CCSDS reliable bitstream. 139 Given the prevalence of IP in many networks, it is likely that two 140 waists exist; IP and HTTP are likely choices, but the transport 141 protocol and physical enviroment will vary more. An expansion of 142 this argument is given in [Wood09b] 144 Separation of HTTP from the underlying transport layer to make HTTP a 145 layer in its own right is increasingly likely to happen; this is 146 analogous to the use of different "convergence layers" under the 147 Bundle Protocol. Being able to set what transport layer to use 148 depending on conditions is useful, and a simple configuration 149 specification to do this that supports HTTP-DTN is described in 150 [I-D.wood-tae-specifying-uri-transports]. 152 HTTP use here relies on the three P's - Persistence, Pipelining and 153 the PUT directive. These are all present in the HTTP/1.1 154 specification. 156 This document contains an overview of how HTTP can be simply adapted 157 to the DTN environment by the use of HTTP/1.1 with persistence and 158 pipelining, the PUT and GET directives, and some trivial extra HTTP 159 headers needed to indicate e.g. a destination in the DTN network. 161 The remainder of this specification uses 'file' as a shorthand for 162 'binary object', which may be an HTTP 'object', file with an 163 associated MIMEtype, or other type of contiguous binary data. 165 A significant benefit to use of HTTP is that the well-known MIMEtype 166 mechanism, integral to HTTP, provides hints on what received files 167 are, and what applications should do with them [RFC2045]. The Bundle 168 Protocol does not support MIMEtypes, or any similar mechanism. HTTP/ 169 1.1's use of MIME is specified in [RFC2616] rather than in the 170 separate MIME documents. 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in RFC 2119. [RFC2119] 176 2. Adapting the HTTP delivery mechanism for DTNs 178 Here, HTTP is used as a peer-to-peer protocol in the sense that 179 multiple files may be transferred in both directions simultaneously 180 between two communicating nodes using HTTP for DTN use. There is not 181 intended to be a strict client/user-agent to server relationship as 182 there is in the web. Instead, sending data across a path of six 183 nodes, four nodes between source and destination, will require a 184 minimum of five separate per-hop HTTP transactions between each pair 185 of nodes to move the data onwards to the next node. This breaks the 186 traditional end-to-end control loop and transfer into separate 187 control loops and transfers suitable for the DTN environment. 189 When two nodes come into contact across a local hop or a subnet, a 190 request for files to be copied, stored, and carried onwards can be 191 made by the receiving node issuing an HTTP GET request. 192 Alternatively, the sending node can simply issue a series of HTTP PUT 193 requests once a connection is established, if it believes that 194 putting the data to the receiving node moves it closer to its 195 eventual destination. The receiving node can always reject transfers 196 with error codes. 198 HTTP-DTN is a superset of HTTP/1.1. HTTP/1.1 pipelining and 199 persistence permits multiple PUTs to be made in sequence. Support 200 for these in implementations is crucial to the mechanisms outlined 201 here. (Note that [I-D.natarajan-http-over-sctp] also takes advantage 202 of HTTP pipelining and persistence.) 204 The key to enabling HTTP use for DTN networking is an added Content- 205 Destination: header, which specifies the final destination of the 206 file, and can be used by routing in the HTTP-using applications to 207 decide over which available links the file should be sent. Content-* 208 headers are special, in that they may not be ignored (section 9.6 of 209 [RFC2616]). Recipients not understanding Content-Destination: will 210 generate a "501 (Not Implemented)" error code. This separates HTTP 211 use in DTNs described here from normal end-to-end HTTP web use. HTTP 212 DTN nodes MUST support Content-Destination:. Files that are PUT are 213 cached and then relayed onwards by intermediate peers to the Content- 214 Destination:. GET requests for files can be forwarded by 215 intermediate peers to the Content-Destination:. 217 The information provided in Content-Destination: identifying the 218 destination may be an IP address, DNS name, Bundle Endpoint 219 Identifier (EID) or other text-string identifier useful to the local 220 DTN routing mechanisms being used. 222 Similarly, a Content-Source: header provides a textual identification 223 of the original source of the data. HTTP-DTN nodes MUST support 224 Content-Source:. 226 For DTN use, DTN HTTP nodes MUST also implement and use Content- 227 Length: and Content-Range: headers. These permit partial delivery of 228 files and resends of missing pieces of files. The Content-MD5: 229 header must be supported. This provides a simple end-to-end 230 reliability check. The Content-MD5: header is intended to be 231 generated by the source node first sending the data, and is not 232 recomputed at other nodes. 234 DTN HTTP nodes MUST implement the Host: header, in line with current 235 HTTP specifications. This header field MAY be left blank to request 236 available files from the peer node, rather than identifying a desired 237 file from a distant source by hostname matching the advertised 238 Content-Source: header. A sender placing a new file into the DTN 239 network for onward transmission MUST have the Content-Source: field 240 of the data being sent match its Host: field. 242 Hop-by-hop HTTP headers MAY be implemented between peer nodes talking 243 directly. The headers described in section 13.5.1 of [RFC2616] are 244 available. New hop-by-hop headers MUST use the Connection: header 245 approach described in section 14.10 of [RFC2616]. 247 DTN HTTP nodes may optionally GET from and PUT to link-local IP 248 multicast addresses when used over IP subnets. This permits 249 efficient sharing of files on shared LANs, with recipients requesting 250 resends via Content-Range: and checking assembly of file pieces using 251 the Content-MD5: header. A GET to multicast can request a specific 252 file from any available node that has it. The response to a 253 multicast GET SHOULD be unicast, but a multicast HEAD MAY also be 254 sent to inform other nodes that the sender has the file of interest. 255 If other nodes also express interest in the file with GET requests to 256 the sender, that file may later be PUT to a multicast address. 258 (Note that in the alternative Bundle Protocol, the Bundle Endpoint 259 Identifier (EID) can identify a group of endpoints, rather than just 260 one; mapping the Bundle EID onto multicast IP adddresses on IP 261 subnets is possible. Placing textual EIDs directly in HTTP-DTN's 262 Content-Source: and Content-Destination: headers, or in a Host: 263 field, would be possible to interwork HTTP-DTN and bundling.) 265 The utility of HTTP with multicast has been recognised previously as 266 a method of simple service discovery later adopted for the universal 267 plug and play (UPnP) protocol [I-D.draft-goland-http-udp] 268 [I-D.draft-cai-ssdp-v1]. Rather than call out multicast and unicast 269 separately as different protocols to be used by HTTP, recognising 270 that a given destination or address indicates multicast or broadcast 271 use should suffice. 273 Many existing HTTP/1.1 headers are directly useful with HTTP-DTN. 274 For example, ETag: headers are useful for identifying unique copies 275 of files in the network, and can be used to provide globally unique 276 identifiers (GUIDs) for each version of a file. Age: headers are 277 useful for estimating the amount of time a MIME object has been in 278 the network - indicating both transmission and storage times. Last- 279 Modified: times refer to the times on the origin server - that is, 280 the Content-Source: - and should be preserved during onward 281 forwarding. Max-Forwards: provides a TTL hop count and propagation 282 limitation mechanism. 284 3. Other useful proposed additional HTTP headers 286 A number of other additional HTTP headers are proposed here, as 287 likely to be useful. These SHOULD be implemented. These would 288 benefit from being specified more completely, in line with the 289 suggestions in [RFC2774]. 291 An HTTP object is just one binary file; the ability to group objects 292 together is useful (and is done in bundles by the Bundle Protocol). 293 If we call a group of related objects sent from the same source to 294 the same destination a 'package' (a name chosen to avoid any 295 confusion with the Bundle Protocol specification), we can then define 296 simple headers to be sent before each object: 298 Package-ID: - provides a unique textual identifier for the package 300 Package-Item: n of m (e.g. 1 of 7) - order of this HTTP file in the 301 package 303 Package-MD5: - MD5 hash across all Content-MD5: headers added 304 together in order of Package-Item: precedence. 306 A way to request missing Package-Items (from the previous node or 307 from the source) is likely to be very useful. 309 Precedence: headers could set importance of objects - very-high, 310 high, normal low, very-low - to give simple quality of service and 311 prioritization. 313 Some sort of header protection may be a good idea; Content-MD5: 314 covers the message body (entity-body), but not the headers. Header- 315 MD5: could cover some important HTTP headers. Header-MD5 could be 316 preserved across hops if possible, avoiding unnecessary header 317 reordering. Changing timestamps would invalidate the Header-MD5: 318 end-to-end, however - this needs more thought, particularly on where 319 timestamps are placed in HTTP headers. 321 For larger files, stronger mechanisms than MD5 should be examined. 323 There may be a need to send HTTP-DTN transfers across paths that 324 include hops with unidirectional one-way links with no return path, 325 e.g. when a wireless sender knows that a receiver is available, but 326 cannot hear it. Using: Connection: cannot-hear-response could be 327 used across that hop to indicate that the sender cannot hear 328 receivers. 330 Timestamps and how they are handled needs to be examined here in 331 greater detail. HTTP has the same basic assumption as the Bundle 332 Protocol - that all nodes are expected to know the current UTC time. 334 4. Other suggestions on using MIME in DTN networks 336 x-application-dtn has previously been proposed as a MIMEtype 337 identifying Bundle Protocol bundles delivered by HTTP. This provides 338 a way to support Bundle Protocol implementations in an HTTP 339 infrastructure. 341 Moving HTTP transfers over DTN networks using the Bundle Protocol has 342 already been proposed [Ott06]. By changing how HTTP is used - hop- 343 by-hop rather than end-to-end - HTTP can be used directly in DTN 344 networks without using the Bundle Protocol at all. 346 HTTP is a popular way to carry MIME, but support for MIME exists in 347 other protocols, including email, SIP and BEEP. BEEP can be thought 348 of as a more formalised and exactly-specified replacement for HTTP 349 for machine-machine interaction - and this detailed formal 350 specification makes BEEP complex [RFC3080]. BEEP provides an 351 alternative to HTTP to support XML-RPC and SOAP. BEEP's 352 specification is formally intended to support multiple different 353 transports, but only TCP transport of BEEP has been agreed [RFC3081]. 355 HTTP's simplicity of use and popularity appear to be compelling 356 advantages over BEEP. 358 5. Security Considerations 360 Better-Than-Nothing Security [RFC5386][RFC5387] is likely to be 361 useful here for ad-hoc communications without the availability of an 362 existing authentication infrastructure. 364 Security considerations and detailed examination of HTTP over TLS 365 (HTTPS) [RFC2817][RFC2818] and secure HTTP [RFC2660] are required 366 here. 368 Many existing security mechanism for HTTP could be used unchanged for 369 HTTP-DTN, if local conditions permit and the supporting 370 infrastructure, e.g. DNS, is available. However, reusing these 371 directly protects a single-hop transfer between peer nodes. To 372 protect an end-to-end transfer, the security mechanisms would need to 373 be applied using the information used in the Content-Source: and 374 Content-Destination: headers, before applying the local security 375 mechanism for the first peer-peer HTTP transfer. 377 6. IANA Considerations 379 Despite the Content-* rule for rejecting unfamiliar headers that 380 separates HTTP-DTN peers from traditional HTTP servers, it may be 381 desirable to use a non-standard port for DTN HTTP use over IP, rather 382 than the well-known port 80. If so, such a port should be requested 383 from IANA. 385 It may be necessary to request a dedicated IPv4 all-hosts multicast 386 address and a dedicated IPv6 link-local multicast addresses for local 387 HTTP DTN use, if local HTTP multicast is considered a desirable 388 feature. 390 7. Acknowledgements 392 We thank Wes Eddy and Kevin Fall for their review comments. 394 Work on the Saratoga protocol inspired some of the concepts that are 395 reused here, and we thank everyone involved in Saratoga's development 396 and implementation. 398 8. References 399 8.1. Normative References 401 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 402 Requirement Levels", BCP 14, RFC 2119, March 1997. 404 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 405 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 406 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 408 [RFC2774] Nielsen, H., Leach, P., and S. Lawrence, "An HTTP 409 Extension Framework", RFC 2774, February 2000. 411 8.2. Informative References 413 [Deering98] 414 Deering, S., "Watching the Waist of the Protocol 415 Hourglass", keynote, IEEE International Conference on 416 Network Protocols (ICNP), Austin Texas, October 1998. 418 [I-D.draft-cai-ssdp-v1] 419 Goland, Y., Cai, T., Leach, P., Gu, Y., and S. Albright, 420 "Simple Service Discovery Protocol/1.0 Operating without 421 an Arbiter", draft-cai-ssdp-v1-03 (expired) , 422 October 1999. 424 [I-D.draft-goland-http-udp] 425 Goland, Y., "Multicast and Unicast UDP HTTP Messages", 426 draft-goland-http-udp-01 (expired) , November 1999. 428 [I-D.irtf-dtnrg-bundle-checksum] 429 Eddy, W., Wood, L., and W. Ivancic, "Reliability-only 430 Ciphersuites for the Bundle Protocol", 431 draft-irtf-dtnrg-bundle-checksum-06 (work in progress) , 432 October 2009. 434 [I-D.natarajan-http-over-sctp] 435 Natarajan, P., Amer, P., Leighton, J., and F. Baker, 436 "Using SCTP as a Transport Layer Protocol for HTTP", 437 draft-natarajan-http-over-sctp-02 (work in progress), 438 July 2009. 440 [I-D.wood-tae-specifying-uri-transports] 441 Wood, L., "Specifying transport mechanisms in Uniform 442 Resource Identifiers", 443 draft-wood-tae-specifying-uri-transports-07 (work in 444 progress) , October 2009. 446 [I-D.wood-tsvwg-saratoga] 447 Wood, L., McKim, J., Eddy, W., Ivancic, W., and C. 448 Jackson, "Saratoga: A Scalable File Transfer Protocol", 449 draft-wood-tsvwg-saratoga-04 (work in progress) , 450 October 2009. 452 [Ott06] Ott, J. and D. Kutscher, "Bundling the Web: HTTP over 453 DTN", WNEPT 2006 Workshop on Networking in Public 454 Transport, QShine Conference, Ontario, August 2006. 456 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 457 Extensions (MIME) Part One: Format of Internet Message 458 Bodies", RFC 2045, November 1996. 460 [RFC2660] Rescorla, E. and A. Schiffman, "The Secure HyperText 461 Transfer Protocol", RFC 2660, August 1999. 463 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 464 HTTP/1.1", RFC 2817, May 2000. 466 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 468 [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", 469 RFC 3080, March 2001. 471 [RFC3081] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, 472 March 2001. 474 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 475 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 476 Networking Architecture", RFC 4838, April 2007. 478 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 479 Specification", RFC 5050, November 2007. 481 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing 482 Security: An Unauthenticated Mode of IPsec", RFC 5386, 483 November 2008. 485 [RFC5387] Touch, J., Black, D., and Y. Wang, "Problem and 486 Applicability Statement for Better-Than-Nothing Security 487 (BTNS)", RFC 5387, November 2008. 489 [Wood09a] Wood, L., Eddy, W., and P. Holliday, "A Bundle of 490 Problems", IEEE Aerospace Conference, Big Sky, Montana, 491 March 2009. 493 [Wood09b] Wood, L., Holliday, P., Floreani, D., and I. Psaras, 494 "Moving data in DTNs with HTTP and MIME: Making use of 495 HTTP for delay- and disruption-tolerant networks with 496 convergence layers", Workshop on the Emergence of Delay-/ 497 Disruption-Tolerant Networks (e-DTN 2009), St Petersburg, 498 Russia, October 2009. 500 Authors' Addresses 502 Lloyd Wood 503 Surrey, England 505 Email: L.Wood@society.surrey.ac.uk 507 Peter Holliday 508 Cisco Systems 509 Level 12 510 300 Adelaide Street 511 Brisbane, Queensland 4000 512 Australia 514 Phone: +61-2-6216-0604 515 Email: phollida@cisco.com