idnits 2.17.1 draft-davies-dtnrg-uri-find-01.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 date (October 26, 2009) is 5289 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3986' is defined on line 345, but no explicit reference was found in the text == Unused Reference: 'RFC2683' is defined on line 366, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4395 (Obsoleted by RFC 7595) -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) Summary: 2 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 E. Davies 3 Internet-Draft Folly Consulting 4 Intended status: Informational A. Doria 5 Expires: April 29, 2010 LTU 6 October 26, 2009 8 Adding the "find" Operation to the dtn: URI Scheme 9 draft-davies-dtnrg-uri-find-01.txt 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 29, 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 discusses the addition of a new operation to the 48 proposed dtn: URI (Uniform Resource Identifier) scheme. The new 49 "find" operation would provide support for DTN (Delay- and 50 Disruption-Tolerant Network) anycast services. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 3 56 3. Changes to "dtn" Scheme Syntax and Rules . . . . . . . . . . . 4 57 3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.2. Changes to Resolution of DTN Endpoint IDs . . . . . . . . . 4 59 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4.1. Services Delivered by Local Service Agents . . . . . . . . 5 61 4.1.1. dtn:find:mailto:another@example.org,second@example.org 5 62 4.1.2. dtn:find:service:printer?printer-color-supported=true . 5 63 4.1.3. dtn:find:service:fax?destination=+4416324960123 . . . . 5 64 4.1.4. dtn:find:service:httpproxy:http://example.com/somepage. 5 65 4.1.5. dtn:find:service:httpproxy:http:?telephone+number+e 66 &width=5,&depth=3 . . . . . . . . . . . . . . . . . . . 6 67 4.2. Services Delivered by Forwarding the Bundle Using 68 Alternative Addressing . . . . . . . . . . . . . . . . . . 6 69 4.2.1. dtn:find:intent#role(?E,coffee),location(?E,Loc),within 6 70 4.2.2. dtn:find:assoc:wanderer3.base1.example.dtn . . . . . . 7 71 4.2.3. dtn:find:dns:foo.bar.example.net . . . . . . . . . . . 7 72 4.2.4. dtn:find:ipv4:192.0.2.27 . . . . . . . . . . . . . . . 7 73 4.2.5. dtn:find:ipv6:[2001:db8::27:ef12] . . . . . . . . . . . 7 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 76 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 79 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 This document describes the addition of an extra operation to the 85 proposed dtn: URI (Uniform Resource Identifier) scheme documented in 86 [I-D.irtf-dtnrg-dtn-uri-scheme]. 88 The purpose of the "find" operation is to allow DTN nodes to access 89 services that they do not or cannot support through exchange of DTN 90 bundles. In the spirit of DTN operation, nodes expect to be able to 91 operate independently and may not know exactly where such a service 92 is implemented, but has a reasonable expectation that such a service 93 is provided by another node accessible using DTN. 95 Apart from the usual concept of services such as requesting printing 96 of a bundle payload or accessing a web proxy, the "find" operation 97 can also be used to find gateways onto remote networks that use other 98 forms of addressing than the Endpoint IDs (EIDs) normally used to 99 identify DTN nodes and to route bundles outside the current 100 "association" where the bundles was created. 102 When a bundle arrives at a DTN node that implements the service 103 indicated, the action taken depends on the service requested. In the 104 case of gateway services, the bundle will simply be forwarded to the 105 bundle agent on the addressed node. For other services, the bundle's 106 payload will be passed to the service agent on the node together with 107 any parameters derived from the service specification in the 108 destination URI. 110 In order for the "find" operation to work satisfactorily, the routing 111 service, whether static or dynamic, would need to collect and 112 propagate information about the "services" offered by the nodes to 113 which it was able to route bundles. With the help of this 114 information, the DTN routing system could offer a form of "anycast" 115 service that delivered appropriately addressed bundles to one or more 116 nodes that offer the services requested in the "find" addressing 117 format. Especially in the dynamic case, service announcements will 118 need to be propagated in the DTN network. The mechanism to be used 119 to provide these announcements requires further study. Where 120 services are provided by gateway nodes at the edge of the Internet 121 static configuration in some DTN nodes may be sufficient. 123 2. Requirements Notation 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 3. Changes to "dtn" Scheme Syntax and Rules 131 3.1. Syntax 133 The general syntax of a dtn URI as defined in 134 [I-D.irtf-dtnrg-dtn-uri-scheme] is unchanged except for the addition 135 of "find" to opname. The revised ABNF [RFC5234] is: 137 dtnURI = "dtn:" ("none" / nontrivialSSP) 139 where: 141 nontrivialSSP = dtnURIelt *("!" dtnURIelt) 143 dtnURIelt = [opname] ":" URI ; URI as defined in RFC 3986 [*] 145 opname = "push" / "pop" / "next" / "flood" / "exec"/ "find" 147 3.2. Changes to Resolution of DTN Endpoint IDs 149 Section 2.2 of [I-D.irtf-dtnrg-dtn-uri-scheme] contains definitions 150 of the various operations listed under "opname" in the ABNF. For the 151 "find" operation the following definition should be added after the 152 definition of "exec": 154 find: When the operation name is "find", the bundle agent SHOULD use 155 information accumulated by the DTN routing system in use to 156 forward the bundle towards one or more nodes that are able to 157 deliver the requested service or would be better able to forward 158 the bundle towards such a node. However, the node MAY determine 159 that it is able to deliver the bundle locally to an agent that can 160 provide the requested service: in this case the operation is 161 equivalent to the "pop" operation. If the node is unable to 162 determine a suitable target it MAY drop the bundle. 164 When the bundle is delivered to a node that provides the specified 165 service then, depending on the service specified, the bundle is 166 either forwarded to the bundle agent on a node using an 167 alternative addressing scheme or passed to the service agent for 168 the service on the current node. 170 4. Examples 172 Several examples of the use of the "find" operation are presented 173 split between conventional services delivered by a local service 174 agent, such as a SMTP mail server, and services that provide access 175 to networks using alternative addressing schemes, such as IPv4. 177 4.1. Services Delivered by Local Service Agents 179 In these cases the bundle is passed to a service agent that will 180 generally be expected to decapsulate the bundle and use the payload 181 in combination with any parameters passed in the service description 182 in the dtn: URI to deliver the requested service. 184 4.1.1. dtn:find:mailto:another@example.org,second@example.org 186 Citing this EID as the destination of a bundle causes the bundle to 187 be delivered to a node that provides an (outgoing) email server that 188 can forward the payload of the bundle as an email to the specified 189 address(es) in the mailto URI or local account(s) to which the email 190 can be delivered. In this case the bundle payload is expected to 191 contain one or more emails in [RFC2822] format. 193 4.1.2. dtn:find:service:printer?printer-color-supported=true 195 Citing this EID as the destination of a bundle causes the bundle to 196 be delivered to a node that provides a printing service. The 197 specified attribute requests that a color capable printer be used to 198 print the payload carried in the bundle. This example uses the 199 service: URI template "printer.2.0.en" 200 201 that conforms to the specification in [RFC2609]. 203 4.1.3. dtn:find:service:fax?destination=+4416324960123 205 Citing this EID as the destination of a bundle is intended to cause 206 the bundle to be delivered to a node that provides a telephone 207 facsimile (fax) service. Note that this would require the definition 208 of a new service: URI template for a fax delivery service which 209 provided the "destination" attribute that would be the telephone 210 number called. The payload of the bundle would be sent as a fax to 211 the specified destination. 213 4.1.4. dtn:find:service:httpproxy:http://example.com/ 214 somepage.html?depth=3 216 Citing this EID as the destination of a bundle is intended to cause 217 the bundle to be delivered to a node that provides a (caching) web 218 proxy service. As with the previous example, this proposes the use 219 of a yet-to-be created service: URI template for a web proxy service 220 that would access the specified URI using the HTTP protocol. 221 Typically the HTML in the page returned from the initial request 222 would require additional accesses to build up the entire displayed 223 page (c.f., the GNU "wget" tool that returns content from web servers 224 ). The "depth" parameter controls 225 the depth of recursion of such accesses. The suite of returned HTML 226 documents would be combined into a single bundle that would be 227 returned to the requestor. The complete service would provide 228 additional parameters to control the behavior of the service and 229 possibly cause repeated operation on a timed basis. 231 4.1.5. dtn:find:service:httpproxy:http:?telephone+number+example, 232 &width=5,&depth=3 234 This example is similar to the previous example in Section 4.1.4, 235 except that the intention is to have the service access a suitable 236 web search engine (to be chosen by the service provider) to look up 237 information according to the query (in this case information about 238 example numbers to be used when describing a telephone service) with 239 parameters that control the number of returned results (&width 240 parameter) to be examined in more detail by accessing the returned 241 URIs recursively to the value of the &depth parameter. Again the 242 complete set of results would be returned as a single bundle and 243 additional parameters could be defined. 245 4.2. Services Delivered by Forwarding the Bundle Using Alternative 246 Addressing 248 The examples in this section show how the "find" operation could be 249 used to deliver bundles to nodes that implement a bundle agent but 250 that are also identified by another form of identifier or locator 251 than a "universal" dtn: URI. The means used to deliver the bundle 252 will be dependent on the network technology associated with the 253 addressing format used. 255 In all cases the bundle is forwarded as a bundle rather than being 256 decapsulated. At the destination additional parts of the URI will be 257 used to demultiplex the bundle to the appropriate application to 258 which it is directed as with conventional EID addressing. 260 4.2.1. dtn:find:intent# 261 role(?E,coffee),location(?E,Loc),within(100,(1,3),Loc) 263 The concept of intentional naming is described in 264 [I-D.pbasu-dtnrg-naming]. An example of the naming scheme used with 265 the GRAIN (Gradient-Based Algorithm for Intentional Naming) algorithm 266 to locate nodes that satisfy the intentional naming specification is 267 given at the end of Section 5.5 of the Intentional Naming draft. The 268 mechanism needs additional support from the dtn: URI scheme to be 269 usable in a DTN network. We suggest that the "find" operation could 270 be used in the way illustrated in this example to direct bundles to 271 appropriate nodes using an intentional naming scheme. We also note 272 that it would also be possible to specify the intentional naming 273 mechanism through a service: URI service template which would allow 274 it to be used in the wider Internet instead of defined a separate 275 "intent" URI scheme restricted to DTN. 277 4.2.2. dtn:find:assoc:wanderer3.base1.example.dtn 279 The basic naming scheme for DTN nodes (EIDs) anticipates that names 280 would be globally valid. In order to improve the scaling of DTN 281 networks, the concept of "associations" has been discussed. This 282 usage of the "find" operation would allow a node to be located via a 283 name which was applicable only within a given association. Routing 284 would endeavour to locate a node which was a member of the 285 association or find a suitable gateway that might have such 286 information. 288 4.2.3. dtn:find:dns:foo.bar.example.net 290 In this case the bundle is destined for a node in the IP-addressed 291 Internet that has an entry in the DNS (Domain Name System), which can 292 be looked up to provide an IP address where the bundle can be 293 delivered. The bundle agent "service" could either be accessed 294 through a well-known TCP or UDP port or looked up in a DNS service 295 record. The bundle would be delivered using the TCP or (possibly) 296 the UDP convergence layer. The bundle agent can use IPv4 or IPv6 297 according to what addresses are provided by DNS, the capabilities of 298 the local node and a policy choice if both are available. 300 4.2.4. dtn:find:ipv4:192.0.2.27 302 This example is equivalent to the previous example except that "find" 303 needs to locate a gateway that provides IPv4 connectivity onto the 304 Internet. The forward DNS lookup is not required but it may be 305 necessary to perform a reverse lookup to check that the bundle agent 306 service is available and determine the protocol and port to use. 308 4.2.5. dtn:find:ipv6:[2001:db8::27:ef12] 310 A similar example to Section 4.2.4 but using an IPv6 address. The 311 "find" operation needs to locate a gateway providing IPv6 312 connectivity onto the Internet. 314 5. Security Considerations 316 The addition of the "find" operation does not appear to introduce any 317 extra security issues beyond the considerable challenges already 318 facing DTN security. 320 6. IANA Considerations 322 It is intended that the "find" operation will be folded into the dtn: 323 URI scheme being defined in [I-D.irtf-dtnrg-dtn-uri-scheme] which 324 will be registered in the URI registry defined in [RFC4395]. 326 The "find" operation expects to use URIs following the service: URI 327 scheme ([RFC2609]) and possibly other existing schemes. It may 328 require the definition of new service templates according to the 329 service: URI definition. 331 7. Acknowledgments 333 8. References 335 8.1. Normative References 337 [I-D.irtf-dtnrg-dtn-uri-scheme] 338 Fall, K., Burleigh, S., Doria, A., and J. Ott, "The DTN 339 URI Scheme", draft-irtf-dtnrg-dtn-uri-scheme-00 (work in 340 progress), March 2009. 342 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 343 Requirement Levels", BCP 14, RFC 2119, March 1997. 345 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 346 Resource Identifier (URI): Generic Syntax", STD 66, 347 RFC 3986, January 2005. 349 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 350 Registration Procedures for New URI Schemes", BCP 35, 351 RFC 4395, February 2006. 353 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 354 Specifications: ABNF", STD 68, RFC 5234, January 2008. 356 8.2. Informative References 358 [I-D.pbasu-dtnrg-naming] 359 Basu, P., Brown, D., Polit, S., and R. Krishnan, 360 "Intentional Naming in DTN", draft-pbasu-dtnrg-naming-00 361 (work in progress), May 2009. 363 [RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service Templates 364 and Service: Schemes", RFC 2609, June 1999. 366 [RFC2683] Leiba, B., "IMAP4 Implementation Recommendations", 367 RFC 2683, September 1999. 369 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 370 April 2001. 372 Authors' Addresses 374 Elwyn B. Davies 375 Folly Consulting 376 Soham, Cambs 377 UK 379 Phone: +44 7889 488 335 380 Email: elwynd@dial.pipex.com 382 Avri Doria 383 LTU 384 Lulea, 971 87 385 Sweden 387 Phone: +1 401 663 5024 388 Email: avri@acm.org