One document matched: draft-irtf-dtnrg-dtn-uri-scheme-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="exp" docName="draft-irtf-dtnrg-dtn-uri-scheme-00"
ipr="trust200902">
<front>
<title abbrev="The DTN URI Scheme">The DTN URI Scheme</title>
<author fullname="Kevin Fall" initials="K." surname="Fall">
<organization>Intel Research Berkeley</organization>
<address>
<postal>
<street>2150 Shattuck Avenue, #1300</street>
<city>Berkeley</city>
<code>94704</code>
<region>California</region>
<country>USA</country>
</postal>
<phone>+1-510-495-3014</phone>
<facsimile></facsimile>
<email>kfall@intel.com</email>
</address>
</author>
<author fullname="Scott Burleigh" initials="S." role="editor"
surname="Burleigh">
<organization>Jet Propulsion Laboratory</organization>
<address>
<postal>
<street>4800 Oak Grove Drive, m/s 301-490</street>
<city>Pasadena</city>
<region>California</region>
<code>91109</code>
<country>USA</country>
</postal>
<phone>+1-818-393-3353</phone>
<facsimile></facsimile>
<email>scott.c.burleigh@jpl.nasa.gov</email>
<uri></uri>
</address>
</author>
<author fullname="Avri Doria" initials="A." surname="Doria">
<organization abbrev="Lulea University of Technology">Lulea University
of Technology</organization>
<address>
<postal>
<city>Lulea</city>
<code>971 87</code>
<country>Sweden</country>
</postal>
<email>avri@ltu.se</email>
</address>
</author>
<author fullname="Joerg Ott" initials="J." surname="Ott">
<organization abbrev="Helsinki University of Technology">Helsinki
University of Technology</organization>
<address>
<postal>
<street>Department of Communications and Networking</street>
<street>PO Box 3000</street>
<city>TKK</city>
<code>02015</code>
<country>Finland</country>
</postal>
<email>jo@netlab.tkk.fi</email>
</address>
</author>
<author fullname="David Young" initials="D." surname="Young">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date day="28" month="March" year="2009" />
<workgroup>Network Working Group</workgroup>
<keyword>DTN</keyword>
<keyword>delay-tolerant networking</keyword>
<abstract>
<t>This document describes the "dtn" Uniform Resource Identifier (URI)
scheme. DTN URIs are used as DTN endpoint identifiers (EIDs).</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>A DTN endpoint identifier (EID) is a type of Uniform Resource
Identifier (URI) [*] designed to meet the requirements for endpoint
identification as defined in the Bundle Protocol specification, RFC 5050
[*]:</t>
<t><list style="symbols">
<t>EIDs are used to identify the source and destination endpoints of
a bundle, the endpoint to which bundle status reports pertaining to
the bundle are to be sent, and the current custodian of the
bundle.</t>
<t>EIDs are used, as needed, to identify other endpoints that are
involved in the conveyance of a bundle from its source to its
destination. For example, the most recent forwarder of a bundle may
be identified by EID in some block of the bundle.</t>
<t>The length of the scheme-specific part of an EID MUST NOT exceed
1023 bytes.</t>
</list>Any URI whose scheme-specific part is of no more than 1023
bytes MAY be used as a DTN endpoint identifier, regardless of scheme.
However, DTN routers may be configured only to forward bundles to
destinations whose EIDs conform to more restrictive rules; in
particular, bundles destined for endpoints identified by URIs in schemes
other than "dtn" are likely to be unforwardable.</t>
<t>EIDs formed in the "dtn" scheme are specifically designed to be
parseable by DTN routers, increasing the likelihood that the bundles to
which they are destined may be forwarded.</t>
<t>Additional information about the dtn URI scheme - motivation,
genesis, and discussion - can be obtained from http://www.dtnrg.org.</t>
<t>Note that this draft represents early thinking on this topic and the
scheme described here is very likely to change in many respects as we
get further input from DTNRG. The authors welcome further discussion and
comments.</t>
</section>
<section title=""dtn" Scheme Syntax and Rules">
<t>This section specifies the syntax of dtn URIs, then discusses the
resolution of DTN endpoint IDs.</t>
<section title="Syntax">
<t>The general syntax of a dtn URI, in ABNF [*], is:</t>
<t><list style="empty">
<t>dtnURI = "dtn:" ("none" / nontrivialSSP)</t>
</list>where:</t>
<t><list style="empty">
<t>nontrivialSSP = dtnURIelt *("!" dtnURIelt)</t>
<t>dtnURIelt = [opname] ":" URI ; URI as defined in RFC 3986
[*]</t>
<t>opname = "push" / "pop" / "next" / "flood" / "exec"</t>
</list></t>
</section>
<section title="Resolution of DTN Endpoint IDs">
<t>Whenever the scheme-specific part (SSP) of a "dtn" URI is not
"none" - that is, it is non-trivial - this SSP comprises one or more
dtn URI elements, each of which comprises an optional operation name
followed by a URI. (That is, each non-trivial "dtn" URI's SSP contains
at least one embedded URI.) The scheme component of the embedded URI
in each dtn URI element identifies the name space from which the
name-specific string (NSS) of that URI - the characters following the
colon that terminates the scheme component - is drawn and in so doing
it indicates the syntax rules governing the NSS.</t>
<t>The scheme component of the embedded URI in a dtn URI element MAY
be some name that is not the name of a registered URI scheme. When the
scheme component of the embedded URI in a DTN URI element is the name
of a registered URI scheme, the syntax of the NSS of that embedded URI
MUST conform to the syntax rules defined for the registered URI
scheme. Otherwise, determining the applicable syntax rules for the NSS
of the embedded URI is an implementation issue.</t>
<t>Each URI element in a "dtn" URI's SSP constitutes a single bundle
handling request, identifying some handling that the bundle agent
SHOULD perform when it is required to dispatch a bundle destined for
the endpoint identified by the "dtn" URI. When the URI comprises
multiple URI elements, the handling performed in response to each
handling request MUST either (a) be performed after any handling
performed in response to all preceding requests and be performed
before any handling performed in response to all subsequent requests
or (b) not be performed. Note that in some cases the handling
requested by a given URI element may be precluded by the performance
of handling requested by a preceding URI element, leaving the bundle
agent with no alternative but to fail to perform the requested
handling.</t>
<t><spanx style="strong">Note that the opnames identified in the "dtn" scheme syntax defined above are merely those that are currently proposed, and the handling defined below for each operation is purely notional at this point.</spanx></t>
<t>The handling requested by each URI element of a destination EID is
defined as follows:</t>
<t><list style="hanging">
<t hangText="push:">When the operation name is "push", the bundle
agent MUST regard the URI in the URI element as the convergence
layer protocol endpoint to which the bundle is to be sent and
SHOULD invoke the services of the applicable convergence layer
adapter to send the bundle to that endpoint. This handling is
intended to supersede any decision on binding proximate node to
convergence layer that the bundle agent might make in the absence
of this handling request.</t>
<t hangText="pop:">When the operation name is "pop", the bundle
agent MUST regard the URI in the URI element as the Internet
application endpoint to which the payload of the bundle is to be
sent and SHOULD invoke Internet services to send the payload of
the bundle to that application endpoint. This handling is intended
to provide a generalized mechanism for directing bundle payloads
to proxies for Internet applications.</t>
<t hangText="next:">When the operation name is "next", the bundle
agent MUST regard the concatentation of the string "dtn::" and the
URI in the URI element as the DTN endpoint to which the bundle
agent is to forward the bundle and SHOULD forward the bundle to
that endpoint. This handling is intended to supersede any
dispatching decision that the bundle agent might make in the
absence of this handling request.</t>
<t hangText="flood:">When the operation name is "flood", the
bundle agent MUST regard the URI in the URI element as a node
selection expression and SHOULD (a) deliver the bundle to the
administrative endpoint of the node if the state of the node
satisfies the selection expression and (b) forward the bundle to
all of the node's neighbors other than the one from which the
bundle was received. This handling is intended to provide a
generalized mechanism for content-based addressing.</t>
<t hangText="exec:">When the operation name is "exec", the bundle
agent MUST regard the URI in the URI element as the definition of
a procedure expressed in a programming language and SHOULD execute
that procedure in the context of the state of the node. This
handling is intended to provide a generalized mechanism for
programmable forwarding.</t>
<t>When no operation name is present, the bundle agent MUST regard
the concatentation of the string "dtn::" and the URI in the URI
element as the name of the destination of the bundle and SHOULD
dispatch the bundle as prescribed in RFC5050.</t>
</list>Following the completion of all performance of handling
requested by the URI elements of a destination EID, if the bundle has
not yet been either forwarded or delivered then the bundle agent MUST
regard the entire destination EID as the name of the destination of
the bundle and MUST dispatch the bundle as prescribed in RFC 5050.</t>
<t>The results of any prior handling performed by the bundle agent MAY
affect the dispatching of a bundle in implementation-specific
ways.</t>
<t>Note that one possible use of a succession of URI elements with
operation names "next" and "push" in an EID is to provide a loose
source route, prescribing the forwarding of a bundle along a specified
sequence of network hops.</t>
</section>
</section>
<section title="Examples">
<t></t>
<section title="dtn:none ">
<t>Citing this endpoint ID, the "null endpoint", as the destination of
a bundle causes the bundle to be discarded.</t>
</section>
<section title="dtn::http://demmermac.dtn/ping">
<t>Citing this EID as the destination of a bundle causes the bundle
simply to be dispatched: it is delivered to the indicated endpoint ID
if the local node is registered at that EID, and otherwise it is
forwarded to that endpoint.</t>
</section>
<section title="dtn::ipn:19.6">
<t>Citing this EID as the destination of a bundle again causes the
bundle simply to be dispatched, as in example 2. Note that in this
case the NSS of the URI embedded in the EID's first URI element is
simply the string "19.6".</t>
</section>
<section title="dtn:pop:http://www.dtnrg.org/log/">
<t>Citing this EID as the destination of a bundle causes the payload
of the bundle to be sent as an HTTP message to the indicated Web site.
Note that this differs from example 2 in that (a) only the payload,
not the entire bundle, is transmitted and (b) the protocol used for
transmission is HTTP rather than Bundle Protocol. In example 2, the
presence of the scheme name "http" identifies the syntax rules
governing the name text but does <spanx style="strong">not</spanx>
cause the HTTP protocol to be used.</t>
</section>
<section title="dtn:pop:mailto:kscott@mitre.org ">
<t>Citing this EID as the destination of a bundle causes the payload
of the bundle to be sent as an email message to the indicated email
address.</t>
</section>
<section title="dtn:push:ethernet:00:1e:24:82:c3:df ">
<t>Citing this EID as the destination of a bundle causes the bundle to
be passed to the Ethernet convergence layer adapter for transmission
to the indicated Ethernet address. This implies an expectation that an
Ethernet convergence layer adapter of some other DTN node is listening
for bundle traffic at this address and will, upon reception of the
bundle, pass it up to that node's bundle agent for dispatching.</t>
</section>
<section title="dtn:push:tcp:119.61.32.4,1816!next:ipn:19.4">
<t>Citing this EID as the destination of a bundle causes the bundle to
be passed to the TCP/IP convergence layer adapter for transmission to
the indicated port on the indicated host. The implied expectation is
that a TCP convergence layer adapter of some other DTN node is
listening for bundle traffic at this port on this host and will, upon
reception of the bundle, pass it up to that node's bundle agent for
dispatching. That bundle agent, recognizing (in an
implementation-dependent manner) that the first URI element in the
destination EID is inapplicable, will ignore that first URI element
and will respond only to the second URI element. The second URI
element requests that the bundle agent immediately forward the bundle
to the endpoint identified by "dtn::ipn:19.4" rather than perform
standard dispatch procedures. That is, this EID prescribes a source
route including selection of a specific initial convergence-layer
channel.</t>
</section>
<section title="dtn:flood:sql:true ">
<t>Citing this EID as the destination of a bundle causes the bundle to
be delivered to the local node's administrative endpoint (because the
node's state is satisfied by the selection expression "true") and then
forwarded to all of the node's neighbors other than the one from which
the bundle was received.</t>
</section>
<section title="dtn:flood:sql:batterylevel<.25">
<t>Citing this EID as the destination of a bundle causes the bundle to
be delivered to the local node's administrative endpoint, provided the
"batterylevel" variable in the state of the node has a value less than
.25, and then forwarded to all of the node's neighbors other than the
one from which the bundle was received.</t>
</section>
<section title="dtn:exec:c:while(foo < 9){bar();foo++;} ">
<t>Citing this EID as the destination of a bundle causes function
"bar" to be executed so long as the value of node state variable "foo"
is less than 9. As soon as "foo" is 9 or greater, all requested
handling for this destination endpoint ID is complete; if execution of
function "bar" has not yet caused the bundle to be dispatched, the
bundle is dispatched at this time. Since, for this purpose, the entire
destination EID must be regarded as the name of the destination, the
node's routing mechanism might require an a default dispatching
decision for all bundles whose destination names conform to the
wild-card expression "dtn:exec:*". This is an implementation
matter.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>The IANA has registered the dtn URI scheme as specified in this
document and summarised in the following template.</t>
<t>URI scheme name: dtn</t>
<t>Status: permanent</t>
<t>URI scheme syntax: see Section 2</t>
<t>Character encoding considerations: none</t>
<t>Intended usage: see Sections 1 through 3</t>
<t>Applications and/or protocols that use this URI scheme name: Any
applications and protocols that use the DTN Bundle Protocol.</t>
<t>Interoperability considerations: none</t>
<t>Security considerations: see Section 5</t>
<t>Relevant publications: RFC 5050</t>
<t>Contact: Kevin Fall(kfall@intel.com) and Stephen Farrell
(stephen.farrell@cs.tcd.ie)</t>
<t>Author/Change controller: Kevin Fall and Stephen Farrell</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>dtn URIs whose URI elements lack operation names or are confined to
the operation names "push" and "next" raise no security considerations
beyond those addressed in RFC 5050.</t>
<t>The "pop" operation could be used to circumvent firewall rules that
accept Bundle Protocol traffic but reject traffic destined for endpoints
of the popped Internet application protocol.</t>
<t>Attacks built on the "flood" operation could exploit the possible
side effects of evaluating selection expressions.</t>
<t>Attacks built on the "exec" operation could modify bundle node state
in a limitless variety of ways.</t>
<t>Bundle protocol implementations that support these more dangerous
operations will need to exercise extreme care.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>[We can only have up to 5 authors, so Stephen, Joseph, Elwyn, and
others need to be acknowledged here.)</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
</references>
<references title="Informative References">
<reference anchor="InfRef">
<front>
<title></title>
<author>
<organization></organization>
</author>
<date year="2004" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:47:36 |