Network Working Group E. Davies Internet-Draft Folly Consulting Intended status: Informational A. Doria Expires: April 12, 2010 LTU October 09, 2009 Adding the "find" Operation to the dtn: URI Scheme draft-davies-dtnrg-uri-find-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 12, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document discusses the addition of a new operation to the proposed dtn: URI (Uniform Resource Identifier) scheme. The new Davies & Doria Expires April 12, 2010 [Page 1] Internet-Draft Adding find opname to dtn: URI October 2009 "find" operation would provide support for DTN anycast services. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 3 3. Changes to "dtn" Scheme Syntax and Rules . . . . . . . . . . . 3 3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Changes to Resolution of DTN Endpoint IDs . . . . . . . . . 4 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. dtn:find:mailto:another@example.org,second@example.org . . 4 4.2. dtn:find:service:printer?printer-color-supported=true . . . 4 4.3. dtn:find:service:fax?destination=+4416324960123 . . . . . . 4 4.4. dtn:find:service:httpproxy:http://example.com/somepage.html 5 4.5. dtn:find:service:httpproxy:http:?telephone+number+examp &width=5,&depth=3 . . . . . . . . . . . . . . . . . . . . . 5 4.6. dtn:find:intent#role(?E,coffee),location(?E,Loc),within(100 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Davies & Doria Expires April 12, 2010 [Page 2] Internet-Draft Adding find opname to dtn: URI October 2009 1. Introduction This document describes the addition of an extra operation to the proposed dtn: URI (Uniform Resource Identifier) scheme documented in [I-D.irtf-dtnrg-dtn-uri-scheme]. The purpose of the "find" operation is to allow DTN nodes to access services that they do not or cannot support through exchange of DTN bundles. In the spirit of DTN operation, nodes expect to be able to operate independently and may not know exactly where such a service is implemented, but has a reasonable expectation that such a service is provided by another node accessible using DTN. In order for the "find" operation to work satisfactorily, the routing service, whether static or dynamic, would need to collect and propagate information about the "services" offered by the nodes to which it was able to route bundles. With the help of this information, the DTN routing system could offer a form of "anycast" service that delivered appropriately addressed bundles to one or more nodes that offer the services requested in the "find" adressing format. Especially in the dynamic case, service announcements will need to be propagated in the DTN network. The mechanism to be used to provide these announcements requires further study. Where services are provided by gateway nodes at the edge of the Internet static configuration in some DTN nodes may be sufficient. 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Changes to "dtn" Scheme Syntax and Rules 3.1. Syntax The general syntax of a dtn URI as defined in [I-D.irtf-dtnrg-dtn-uri-scheme] is unchanged except for the addition of "find" to opname. The revised ABNF [RFC5234] is: dtnURI = "dtn:" ("none" / nontrivialSSP) where: nontrivialSSP = dtnURIelt *("!" dtnURIelt) Davies & Doria Expires April 12, 2010 [Page 3] Internet-Draft Adding find opname to dtn: URI October 2009 dtnURIelt = [opname] ":" URI ; URI as defined in RFC 3986 [*] opname = "push" / "pop" / "next" / "flood" / "exec"/ "find" 3.2. Changes to Resolution of DTN Endpoint IDs Section 2.2 of [I-D.irtf-dtnrg-dtn-uri-scheme] contains defintions of the various operations listed under "opname" in the ABNF. For the "find" operation the following definition should be added after thedefinition of "exec": find: When the operation name is "find", the bundle agent SHOULD use information accumulated by the DTN routing system in use to forward the bundle towards one or more nodes that are able to deliver the requested service or would be better able to forward the bundle towards such a node. However, the node MAY determine that it is able to deliver the bundle locally to an agent that can provide the requested service: in this case the operation is equivalent to the "pop" operation. If the node is unable to determine a suitable target it MAY drop the bundle. 4. Examples 4.1. dtn:find:mailto:another@example.org,second@example.org Citing this EID as the destination of a bundle causes the bundle to be delivered to a node that provides an (outgoing) email server that can forward the payload of the bundle as an email to the specified address(es) in the mailto URI or local account(s) to which the email can be delivered. In this case the bundle payload is expected to contain one or more emails in [RFC2822] format. 4.2. dtn:find:service:printer?printer-color-supported=true Citing this EID as the destination of a bundle causes the bundle to be delivered to a node that provides a printing service. The specified attribute requests that a color capable printer be used to print the payload carried in the bundle. This example uses the service: URI template "printer.2.0.en" that conforms to the specification in [RFC2609]. 4.3. dtn:find:service:fax?destination=+4416324960123 Citing this EID as the destination of a bundle is intended to cause the bundle to be delivered to a node that provides a telephone facsimile (fax) service. Note that this would require the definition Davies & Doria Expires April 12, 2010 [Page 4] Internet-Draft Adding find opname to dtn: URI October 2009 of a new service: URI template for a fax delivery service which provided the "destination" attribute that would be the telephone number called. The payload of the bundle would be sent as a fax to the specified destination. 4.4. dtn:find:service:httpproxy:http://example.com/ somepage.html?depth=3 Citing this EID as the destination of a bundle is intended to cause the bundle to be delivered to a node that provides a (caching) web proxy service. As with the previous example, this proposes the use of a yet-to-be created service: URI template for a web proxy service that would access the specified URI using the HTTP protocol. Typically the HTML in the page returned from the initial request would require additional accesses to build up the entire displayed page (c.f., the GNU "wget" tool that returns content from web servers ). The "depth" parameter controls the depth of recursion of such accesses. The suite of returned HTML documents would be combined into a single bundle that would be returned to the requestor. The complete service would provide additional parameters to control the behavior of the service and possibly cause repeated operation on a timed basis. 4.5. dtn:find:service:httpproxy:http:?telephone+number+example, &width=5,&depth=3 This example is similar to the previous example in Section 4.4, except that the intention is to have the service access a suitable web search engine (to be chosen by the service provider) to look up information according to the query (in this case information about example numbers to be used when describing a telephone service) with parameters that control the number of returned results (&width parameter) to be examined in more detail by accessing the returned URIs recursively to the value of the &depth parameter. Again the complete set of results would be returned as a single bundle and additional parameters could be defined. 4.6. dtn:find:intent# role(?E,coffee),location(?E,Loc),within(100,(1,3),Loc) The concept of intentional naming is described in [I-D.pbasu-dtnrg-naming]. An example of the naming scheme used with the GRAIN (Gradient-Based Algorithm for Intentional Naming) salgorithm to locate nodes that satisfy the intentional naming specification is given at the end of Section 5.5 of the draft. The mechanism needs additional support from the dtn: URI scheme to be usable in a DTN network. We suggest that the "find" operation could be used in the way illustrated in this example to direct bundles to Davies & Doria Expires April 12, 2010 [Page 5] Internet-Draft Adding find opname to dtn: URI October 2009 appropriate nodes using an intentional naming scheme. We also note that it would also be possible to specify the intentional naming mechanism through a service: URI service template which would allow it to be used in the wider Internet instead of defined a separate "intent" URI scheme restricted to DTN. 5. Security Considerations The addition of the "find" operation does not appear to introduce any extra security issues beyind the considerable challenges already facing DTN security. 6. IANA Considerations It is intended that the "find" operation will be folded into the dtn: URI scheme being defined in [I-D.irtf-dtnrg-dtn-uri-scheme] which will be registered in the URI registry defined in [RFC4395]. The "find" operation expects to use URIs following the service: URI scheme ([RFC2609]) and possibly other existing schemes. It may require the definition of new service templates according to the service: URI definition. 7. Acknowledgments 8. References 8.1. Normative References [I-D.irtf-dtnrg-dtn-uri-scheme] Fall, K., Burleigh, S., Doria, A., and J. Ott, "The DTN URI Scheme", draft-irtf-dtnrg-dtn-uri-scheme-00 (work in progress), March 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006. Davies & Doria Expires April 12, 2010 [Page 6] Internet-Draft Adding find opname to dtn: URI October 2009 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. 8.2. Informative References [I-D.pbasu-dtnrg-naming] Basu, P., Brown, D., Polit, S., and R. Krishnan, "Intentional Naming in DTN", draft-pbasu-dtnrg-naming-00 (work in progress), May 2009. [RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service Templates and Service: Schemes", RFC 2609, June 1999. [RFC2683] Leiba, B., "IMAP4 Implementation Recommendations", RFC 2683, September 1999. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. Authors' Addresses Elwyn B. Davies Folly Consulting Soham, Cambs UK Phone: +44 7889 488 335 Email: elwynd@dial.pipex.com Avri Doria LTU Lulea, 971 87 Sweden Phone: +1 401 663 5024 Email: avri@acm.org Davies & Doria Expires April 12, 2010 [Page 7]