idnits 2.17.1 draft-wood-dtnrg-http-dtn-delivery-09.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 : ---------------------------------------------------------------------------- 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 (June 2, 2014) is 3613 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 (-22) exists of draft-wood-tsvwg-saratoga-15 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 1 error (**), 0 flaws (~~), 2 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 alumni 4 Intended status: Experimental P. Holliday 5 Expires: December 4, 2014 PS&E 6 June 2, 2014 8 Using HTTP for delivery in Delay/Disruption-Tolerant Networks 9 draft-wood-dtnrg-http-dtn-delivery-09 11 Abstract 13 This document describes how to use the Hypertext Transfer Protocol, 14 HTTP, for communication across delay- and disruption-tolerant 15 networks, by making every transit node in the network HTTP-capable, 16 and doing peer HTTP transfers between nodes to move data hop-by-hop 17 or subnet-by-subnet towards its final destination. HTTP is well- 18 known and straightforward to implement in these networks. 20 Status of This Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 4, 2014. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. 49 Table of Contents 51 1. Background and Introduction . . . . . . . . . . . . . . . . . 2 52 2. Adapting the HTTP delivery mechanism for DTNs . . . . . . . . 4 53 3. Other useful proposed additional HTTP headers . . . . . . . . 7 54 4. Other suggestions on using MIME in DTN networks . . . . . . . 8 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 56 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 57 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 58 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 60 8.2. Informative References . . . . . . . . . . . . . . . . . 10 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 63 1. Background and Introduction 65 Delay- and Disruption-Tolerant Networks (DTNs) are networks where 66 conditions are such that links between nodes are not always 67 permanent, may be of very long delay or exist only during very short 68 contact periods where the link is up, and may change over time 69 [RFC4838]. Some DTNs can be thought of as sparse ad-hoc networks, 70 with nodes communicating intermittently only when they come into 71 contact. Store-and-forward delivery of data is a useful way of 72 communicating across these networks. 74 This document outlines how the well-known Hypertext Transfer Protocol 75 (HTTP) [RFC2616] can be used for store-and-forward communication 76 across DTNs. HTTP is not used end-to-end as it is on the web. 77 Instead, applications running on each node in the network communicate 78 with their neighbours using dedicated hop-by-hop or subnet-by-subnet 79 HTTP transfers to effect local data delivery. We call this use 80 "HTTP-DTN." 82 It must be stressed that this proposed use is distinct from proxy 83 caching methods prevalent in the traditional web. Caching commands 84 are not used; end-to-end HTTP requests are not intercepted by 85 intermediate caches that attempt to fulfil them in the traditional 86 web caching sense. 88 Although HTTP-DTN use is as a hop-by-hop message carrier between 89 caches implementing some form of routing protocol between them, the 90 distinction between client, server and proxy is replaced by peer 91 intermediate caches using HTTP to communicate in separate sessions 92 that together combine over time to make the full path between 93 original source and final destination for the data. 95 HTTP is a session layer, running over a transport layer providing 96 reliable delivery of the HTTP stream between hops. This transport 97 layer is commonly (and almost universally) TCP in the terrestrial 98 Internet, although alternative transport layers, such as SCTP, can 99 also be used under HTTP [I-D.natarajan-http-over-sctp]. For long- 100 delay networks, or for network conditions where TCP or an equivalent 101 is not suitable, an alternative transport layer such as Saratoga 102 [I-D.wood-tsvwg-saratoga] can be used under HTTP instead in hop-by- 103 hop communications between nodes. HTTP requires only reliable 104 streaming that can be used to provide ordered delivery; how that 105 reliable streaming is provided is up to the local transport layer in 106 the local subnet, and multiple different transport layers can be used 107 across the multiple hops between nodes to transfer data from source 108 to final destination. 110 Steve Deering has often described IP as 'the waist in the hourglass' 111 [Deering98] - what is above and touching on IP can be changed, what 112 is below and touching on IP can be changed, but provided the new 113 elements continue to interface to and work with IP, the hourglass 114 remains complete and the network stack remains functional. Here, 115 HTTP is the waist in this particular hourglass; applications can use 116 HTTP to communicate, provided HTTP runs over a reliable transport 117 stream. The applications can vary. The transport stream can be 118 changed; HTTP does not have to run over TCP/IP, but could even be 119 made to run directly over e.g. HDLC or a CCSDS reliable bitstream. 120 Given the prevalence of IP in many networks, it is likely that two 121 waists exist; IP and HTTP are likely choices, but the transport 122 protocol and physical enviroment will vary more. An expansion of 123 this argument is given in [Wood09b]. More discussion of HTTP as the 124 new waist of the Internet is given in [Popa12]. 126 A specialised store-and-forward protocol for DTN delivery has been 127 proposed in the IRTF DTN research group (DTNRG) - the Bundle Protocol 128 [RFC5050]. Criticisms of the Bundle Protocol's lack of reliability 129 and its complexity have been made [Wood09a]. The Bundle Protocol is 130 itself intended to be a routable data format, but the supporting 131 architectures for node and application naming/addressing, automated 132 routing, security, QoS, and resource discovery have not yet been 133 agreed upon or in some cases even significantly worked on. These 134 things already exist for the Internet Protocol, and can in many cases 135 be easily leveraged for DTN networks. 137 Additional HTTP header information adds context for onward forwarding 138 and delivery to destination endpoints, and provides the reliability 139 and support for error-detection currently missing from the 140 alternative Bundle Protocol. 142 Separation of HTTP from the underlying transport layer, making HTTP a 143 layer in its own right, is increasingly likely to happen; this is 144 analogous to the use of different "convergence layers" under the 145 Bundle Protocol. Being able to set what transport layer to use 146 depending on conditions is useful, and one simple configuration 147 approach to this, able to support HTTP-DTN, was outlined in 148 [I-D.wood-tae-specifying-uri-transports]. 150 HTTP use here relies on the three P's - Persistence, Pipelining and 151 the PUT directive. These are all present in the HTTP/1.1 152 specification. 154 This document contains an overview of how HTTP can be simply adapted 155 to the DTN environment by the use of HTTP/1.1 with persistence and 156 pipelining, the PUT and GET directives, and some trivial extra HTTP 157 headers needed to indicate e.g. a destination in the DTN network. 159 The remainder of this specification uses 'file' as a shorthand for 160 'binary object', which may be an HTTP 'object', file with an 161 associated MIMEtype, or other type of contiguous binary data. 163 A significant benefit to use of HTTP is that the well-known MIMEtype 164 mechanism, integral to HTTP, provides hints on what received files 165 are, and what applications should do with them [RFC2045]. The Bundle 166 Protocol does not support MIMEtypes, or any similar mechanism. 167 HTTP/1.1's use of MIME is specified in [RFC2616] rather than in the 168 separate MIME RFC documents, but those documents introduce concepts, 169 prevalent in email use of MIME, that can be leveraged here. 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in RFC 2119. [RFC2119] 175 2. Adapting the HTTP delivery mechanism for DTNs 177 Here, HTTP is used as a peer-to-peer protocol in the sense that 178 multiple files may be transferred in both directions simultaneously 179 between two communicating nodes using HTTP for DTN use. There is not 180 intended to be a strict client/user-agent to server relationship as 181 there is in the web. Instead, sending data across a path of six 182 nodes, four nodes between source and destination, will require a 183 minimum of five separate per-hop HTTP transactions between each pair 184 of nodes to move the data onwards to the next node. This breaks the 185 traditional end-to-end control loop and transfer into separate 186 control loops and transfers suitable for the DTN environment. 188 When two nodes come into contact across a local hop or a subnet, a 189 request for files to be copied, stored, and carried onwards can be 190 made by the receiving node issuing an HTTP GET request. 191 Alternatively, the sending node can simply issue a series of HTTP PUT 192 requests once a connection is established, if it believes that 193 putting the data to the receiving node moves it closer to its 194 eventual destination. The receiving node can always reject transfers 195 with error codes. 197 HTTP-DTN is a superset of HTTP/1.1. HTTP/1.1 pipelining and 198 persistence permits multiple PUTs to be made in sequence. Support 199 for these in implementations is beneficial to the mechanisms outlined 200 here. (Note that [I-D.natarajan-http-over-sctp] also takes advantage 201 of HTTP pipelining and persistence.) 203 The key to enabling HTTP use for DTN networking is an added Content- 204 Destination: header, which specifies the final destination of the 205 file, and can be used by routing in the HTTP-using applications to 206 decide over which available links the file should be sent. Content-* 207 headers are special, in that they may not be ignored (section 9.6 of 208 [RFC2616]). Recipients not understanding Content-Destination: will 209 generate a "501 (Not Implemented)" error code. This separates HTTP 210 use in DTNs described here from normal end-to-end HTTP web use. HTTP 211 DTN nodes MUST support the Content-Destination: header. Files that 212 are PUT are cached and then relayed onwards by intermediate peer to 213 the final destination that is indicated by the Content-Destination: 214 header. GET requests for files can be forwarded by intermediate 215 peers to that final destination that is indicated by the Content- 216 Destination: header. 218 The information provided in Content-Destination: identifying the 219 destination may be an IP address, DNS name, Bundle Endpoint 220 Identifier (EID) or other text-string identifier useful to the local 221 DTN routing mechanisms being used. 223 Similarly, a Content-Source: header provides a textual identification 224 of the original source of the data. HTTP-DTN nodes MUST support the 225 Content-Source: header. 227 For DTN use, DTN HTTP nodes MUST also implement and use Content- 228 Length: and Content-Range: headers. These permit partial delivery of 229 files and resends of missing pieces of files. 231 The Content-ID: header [RFC2387] SHOULD be supported. This enables 232 individual files to be identified uniquely within the context of a 233 Content-Source: header, or within the context of the packages that 234 this document introduces later. 236 The Content-MD5: header MUST be supported. This provides a simple 237 end-to-end reliability check. The Content-MD5: header SHOULD be 238 generated by the source node first sending the data. It MAY be 239 checked and recomputed at other nodes for early discards and resends 240 of corrupted data. It SHOULD be checked by the final recipient that 241 is indicated by the Content-Destination: header. Content-MD5 is 242 useful in a reliability-only context in checking for errors, but 243 should not be relied upon for uniqueness, due to the possibility of 244 collisions [RFC6151]. 246 The Content-Disposition: header is useful for specifying local 247 processing and preserving a filename and timestamp information 248 [RFC6266]. 250 DTN HTTP nodes MUST implement the Host: header, in line with current 251 HTTP specifications. This header field MAY be left blank to request 252 available files from the peer node, rather than identifying a desired 253 file from a distant source by hostname matching the advertised 254 Content-Source: header. A sender placing a new file into the DTN 255 network for onward transmission MUST have the Content-Source: field 256 of the data being sent match its Host: field. 258 Hop-by-hop HTTP headers MAY be implemented between peer nodes talking 259 directly. The headers described in section 13.5.1 of [RFC2616] are 260 available. New hop-by-hop headers MUST use the Connection: header 261 approach described in section 14.10 of [RFC2616]. 263 DTN HTTP nodes may optionally GET from and PUT to link-local IP 264 multicast addresses when used over IP subnets. This permits 265 efficient sharing of files on shared LANs, with recipients requesting 266 resends via Content-Range: and checking assembly of file pieces using 267 the Content-MD5: header. A GET to multicast can request a specific 268 file from any available node that has it. The response to a 269 multicast GET SHOULD be unicast, but a multicast HEAD MAY also be 270 sent to inform other nodes that the sender has the file of interest. 271 If other nodes also express interest in the file with GET requests to 272 the sender, that file may later be PUT to a multicast address. 274 (Note that in the alternative Bundle Protocol, the Bundle Endpoint 275 Identifier (EID) can identify a group of endpoints, rather than just 276 one; mapping the Bundle EID onto multicast IP adddresses on IP 277 subnets is possible. Placing textual EIDs directly in HTTP-DTN's 278 Content-Source: and Content-Destination: headers, or in a Host: 279 field, would be possible to interwork HTTP-DTN and bundling.) 281 The utility of HTTP with multicast has been recognised previously as 282 a method of simple service discovery later adopted for the universal 283 plug and play (UPnP) protocol [I-D.draft-goland-http-udp] 284 [I-D.draft-cai-ssdp-v1]. Rather than call out multicast and unicast 285 separately as different protocols to be used by HTTP, recognising 286 that a given destination or address indicates multicast or broadcast 287 use should suffice. 289 Many existing HTTP/1.1 headers are directly useful with HTTP-DTN. 290 For example, ETag: headers are useful for identifying unique copies 291 of files in the network, and can be used to provide globally unique 292 identifiers (GUIDs) for each version of a file. Age: headers are 293 useful for estimating the amount of time a MIME object has been in 294 the network - indicating both transmission and storage times. Last- 295 Modified: times refer to the times on the origin server - that is, 296 the Content-Source: - and should be preserved during onward 297 forwarding. Max-Forwards: provides a TTL hop count and propagation 298 limitation mechanism. 300 3. Other useful proposed additional HTTP headers 302 A number of other additional HTTP headers are proposed here, as 303 likely to be useful. These SHOULD be implemented. These would 304 benefit from being specified more completely, in line with the 305 suggestions in [RFC2774]. 307 An HTTP object is just one binary file; the ability to group objects 308 together is useful (and is done in bundles by the Bundle Protocol). 309 If we call a group of related objects sent from the same source to 310 the same destination a 'package' (a name chosen to avoid any 311 confusion with the Bundle Protocol specification), we can then define 312 simple headers to be sent before each object: 314 Package-ID: - provides a unique textual identifier for the package 316 Package-Item: n of m (e.g. 1 of 7) - order of this HTTP file in the 317 package 319 Package-MD5: - MD5 hash across all Content-MD5: headers added 320 together in order of Package-Item: precedence. 322 A way to request missing Package-Items (from the previous node or 323 from the source) is likely to be very useful. 325 An alternate approach would reuse the Message-ID: header familiar 326 from email [RFC2387], where the Message-ID: collects together a 327 number of unique items identified by their Content-ID: headers. 329 Some way to send a package manifest describing the individual items 330 and sizes would be useful. An HTML webpage includes pointers to all 331 of the files that it depends on; an email includes MIME attachments. 332 XML descriptions may be appropriate in a structured XML document 333 describing properties of the various payloads in the consignment, if 334 there is more than one payload and one item identified by its 335 Content-ID: header. 337 Precedence: headers could set importance of objects - very-high, 338 high, normal low, very-low - to give simple quality of service and 339 prioritization. 341 Some sort of header protection may be a good idea; Content-MD5: 342 covers the message body (entity-body), but not the headers. Header- 343 MD5: could cover some important HTTP headers. Header-MD5 could be 344 preserved across hops if possible, avoiding unnecessary header 345 reordering. Changing timestamps would invalidate the Header-MD5: 346 end-to-end, however - this needs more thought, particularly on where 347 timestamps are placed in HTTP headers. 349 For larger files, stronger mechanisms than MD5 should be examined. 351 There may be a need to send HTTP-DTN transfers across paths that 352 include hops with unidirectional one-way links with no return path, 353 e.g. when a wireless sender knows that a receiver is available, but 354 cannot hear it. Using: Connection: cannot-hear-response could be 355 used across that hop to indicate that the sender cannot hear 356 receivers. 358 Timestamps and how they are handled needs to be examined here in 359 greater detail. HTTP has the same basic assumption as the Bundle 360 Protocol - that all nodes are expected to know the current UTC time. 362 4. Other suggestions on using MIME in DTN networks 364 x-application-dtn has previously been proposed as a MIMEtype 365 identifying Bundle Protocol bundles delivered by HTTP. This provides 366 a way to support Bundle Protocol implementations in an HTTP 367 infrastructure. 369 Moving HTTP transfers over DTN networks using the Bundle Protocol has 370 already been proposed [Ott06]. By changing how HTTP is used - hop- 371 by-hop rather than end-to-end - HTTP can be used directly in DTN 372 networks without using the Bundle Protocol at all. 374 HTTP is a popular way to carry MIME, but support for MIME exists in 375 other protocols, including email, SIP and BEEP. BEEP can be thought 376 of as a more formalised and exactly-specified replacement for HTTP 377 for machine-machine interaction - and this detailed formal 378 specification makes BEEP complex [RFC3080]. BEEP provides an 379 alternative to HTTP to support XML-RPC and SOAP. BEEP's 380 specification is formally intended to support multiple different 381 transports, but only TCP transport of BEEP has been agreed [RFC3081]. 382 HTTP's simplicity of use and popularity appear to be compelling 383 advantages over BEEP. 385 5. Security Considerations 387 Better-Than-Nothing Security [RFC5386][RFC5387] is likely to be 388 useful here for ad-hoc communications without the availability of an 389 existing authentication infrastructure. 391 Security considerations and detailed examination of HTTP over TLS 392 (HTTPS) [RFC2817][RFC2818] and secure HTTP [RFC2660] are required 393 here. 395 Many existing security mechanism for HTTP could be used unchanged for 396 HTTP-DTN, if local conditions permit and the supporting 397 infrastructure, e.g. DNS, is available. However, reusing these 398 directly protects a single-hop transfer between peer nodes. To 399 protect an end-to-end transfer, the security mechanisms would need to 400 be applied using the information used in the Content-Source: and 401 Content-Destination: headers, before applying the local security 402 mechanism for the first peer-peer HTTP transfer. 404 6. IANA Considerations 406 Despite the Content-* rule for rejecting unfamiliar headers that 407 separates HTTP-DTN peers from traditional HTTP servers, it may be 408 desirable to use a non-standard port for DTN HTTP use over IP, rather 409 than the well-known port 80. If so, such a port should be requested 410 from IANA. 412 It may be necessary to request a dedicated IPv4 all-hosts multicast 413 address and a dedicated IPv6 link-local multicast addresses for local 414 HTTP DTN use, if local HTTP multicast is considered a desirable 415 feature. 417 7. Acknowledgements 419 We thank Pedro Arthur Duarte, Wes Eddy and Kevin Fall for their 420 review comments. 422 Work on the Saratoga protocol inspired some of the concepts that are 423 reused here, and we thank everyone involved in Saratoga's development 424 and implementation. 426 8. References 428 8.1. Normative References 430 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 431 Requirement Levels", BCP 14, RFC 2119, March 1997. 433 [RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", 434 RFC 2387, August 1998. 436 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 437 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 438 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 440 [RFC2774] Nielsen, H., Leach, P., and S. Lawrence, "An HTTP 441 Extension Framework", RFC 2774, February 2000. 443 8.2. Informative References 445 [Deering98] 446 Deering, S., "Watching the Waist of the Protocol 447 Hourglass", keynote, IEEE International Conference on 448 Network Protocols (ICNP), Austin Texas, October 1998. 450 [I-D.draft-cai-ssdp-v1] 451 Goland, Y., Cai, T., Leach, P., Gu, Y., and S. Albright, 452 "Simple Service Discovery Protocol/1.0 Operating without 453 an Arbiter", draft-cai-ssdp-v1-03 (expired) , October 454 1999. 456 [I-D.draft-goland-http-udp] 457 Goland, Y., "Multicast and Unicast UDP HTTP Messages", 458 draft-goland-http-udp-01 (expired) , November 1999. 460 [I-D.natarajan-http-over-sctp] 461 Natarajan, P., Amer, P., Leighton, J., and F. Baker, 462 "Using SCTP as a Transport Layer Protocol for HTTP", 463 draft-natarajan-http-over-sctp-02 (work in progress), July 464 2009. 466 [I-D.wood-tae-specifying-uri-transports] 467 Wood, L., "Specifying transport mechanisms in Uniform 468 Resource Identifiers", draft-wood-tae-specifying-uri- 469 transports-08 (work in progress), May 2010. 471 [I-D.wood-tsvwg-saratoga] 472 Wood, L., Eddy, W., Smith, C., Ivancic, W., and C. 473 Jackson, "Saratoga: A Scalable Data Transfer Protocol", 474 draft-wood-tsvwg-saratoga-15 (work in progress), April 475 2014. 477 [Ott06] Ott, J. and D. Kutscher, "Bundling the Web: HTTP over 478 DTN", WNEPT 2006 Workshop on Networking in Public 479 Transport, QShine Conference, Ontario, August 2006. 481 [Popa12] Popa, L., Wendell, P., Ghodsi, A., and I. Stoica, "HTTP: 482 an evolvable narrow waist for the future internet", 483 Technical report UCB-EECS-2012-5, University of California 484 at Berkeley, California, January 2012. 486 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 487 Extensions (MIME) Part One: Format of Internet Message 488 Bodies", RFC 2045, November 1996. 490 [RFC2660] Rescorla, E. and A. Schiffman, "The Secure HyperText 491 Transfer Protocol", RFC 2660, August 1999. 493 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 494 HTTP/1.1", RFC 2817, May 2000. 496 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 498 [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", 499 RFC 3080, March 2001. 501 [RFC3081] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, 502 March 2001. 504 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 505 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 506 Networking Architecture", RFC 4838, April 2007. 508 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 509 Specification", RFC 5050, November 2007. 511 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing 512 Security: An Unauthenticated Mode of IPsec", RFC 5386, 513 November 2008. 515 [RFC5387] Touch, J., Black, D., and Y. Wang, "Problem and 516 Applicability Statement for Better-Than-Nothing Security 517 (BTNS)", RFC 5387, November 2008. 519 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 520 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 521 RFC 6151, March 2011. 523 [RFC6266] Reschke, J., "Use of the Content-Disposition Header Field 524 in the Hypertext Transfer Protocol (HTTP)", RFC 6266, June 525 2011. 527 [Wood09a] Wood, L., Eddy, W., and P. Holliday, "A Bundle of 528 Problems", IEEE Aerospace Conference, Big Sky, Montana, 529 March 2009. 531 [Wood09b] Wood, L., Holliday, P., Floreani, D., and I. Psaras, 532 "Moving data in DTNs with HTTP and MIME: Making use of 533 HTTP for delay- and disruption-tolerant networks with 534 convergence layers", Workshop on the Emergence of Delay 535 -/Disruption-Tolerant Networks (e-DTN 2009), St 536 Petersburg, Russia, October 2009. 538 Authors' Addresses 540 Lloyd Wood 541 University of Surrey alumni 542 Sydney, New South Wales 543 Australia 545 Email: L.Wood@society.surrey.ac.uk 547 Peter Holliday 548 Professional Services and Engineering 549 Brisbane, Queensland 550 Australia 552 Email: peter@ps-e.com.au