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 "find" operation would provide support for DTN anycast services.

Table of Contents

1.  Introduction
2.  Requirements Notation
3.  Changes to "dtn" Scheme Syntax and Rules
    3.1.  Syntax
    3.2.  Changes to Resolution of DTN Endpoint IDs
4.  Examples
    4.1.  dtn:find:mailto:another@example.org,second@example.org
    4.2.  dtn:find:service:printer?printer-color-supported=true
    4.3.  dtn:find:service:fax?destination=+4416324960123
    4.4.  dtn:find:service:httpproxy:http://example.com/somepage.html?depth=3
    4.5.  dtn:find:service:httpproxy:http:?telephone+number+example, &width=5,&depth=3
    4.6.  dtn:find:intent#role(?E,coffee),location(?E,Loc),within(100,(1,3),Loc)
5.  Security Considerations
6.  IANA Considerations
7.  Acknowledgments
8.  References
    8.1.  Normative References
    8.2.  Informative References
§  Authors' Addresses

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] (Fall, K., Burleigh, S., Doria, A., and J. Ott, “The DTN URI Scheme,” March 2009.).

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

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] (Fall, K., Burleigh, S., Doria, A., and J. Ott, “The DTN URI Scheme,” March 2009.) is unchanged except for the addition of "find" to opname. The revised ABNF [RFC5234] (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.) is:

dtnURI = "dtn:" ("none" / nontrivialSSP)

where:

nontrivialSSP = dtnURIelt *("!" dtnURIelt)

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] (Fall, K., Burleigh, S., Doria, A., and J. Ott, “The DTN URI Scheme,” March 2009.) 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] (Resnick, P., “Internet Message Format,” April 2001.) 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" http://www.iana.org/assignments/svrloc-templates/printer.2.0.en that conforms to the specification in [RFC2609] (Guttman, E., Perkins, C., and J. Kempf, “Service Templates and Service: Schemes,” June 1999.).

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 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 http://www.gnu.org/software/wget/). 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 (dtn:find:service:httpproxy:http://example.com/somepage.html?depth=3), 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] (Basu, P., Brown, D., Polit, S., and R. Krishnan, “Intentional Naming in DTN,” May 2009.). 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 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] (Fall, K., Burleigh, S., Doria, A., and J. Ott, “The DTN URI Scheme,” March 2009.) which will be registered in the URI registry defined in [RFC4395] (Hansen, T., Hardie, T., and L. Masinter, “Guidelines and Registration Procedures for New URI Schemes,” February 2006.).

The "find" operation expects to use URIs following the service: URI scheme ([RFC2609] (Guttman, E., Perkins, C., and J. Kempf, “Service Templates and Service: Schemes,” June 1999.)) 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

8.2. Informative References

Authors' Addresses