DTN Research Group J. Ott
Internet-Draft T. Kaerkkaeinen
Intended status: Experimental TKK Netlab
Expires: May 15, 2008 M. Pitkaenen
Helsinki Institute of Physics
(HIP) Technology Programme
November 12, 2007
Application Conventions for Bundle-based Communications
draft-ott-dtnrg-dtn-appl-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 May 15, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Ott, et al. Expires May 15, 2008 [Page 1]
Internet-Draft Application Conventions November 2007
Abstract
This document discusses issues arising when moving the bundle
protocol usage from closed or lab deployments into open,
heterogeneous environments with a variety of usages and applications
carried over common bundle agents. We address naming conventions and
endpoint identifiers, content encapsulation, and on the
identification of application contents.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. DTN Operation in an Open Environment . . . . . . . . . . . . . 4
3. Conventions for DTN EIDs . . . . . . . . . . . . . . . . . . . 6
4. Routing conventions and EIDs . . . . . . . . . . . . . . . . . 8
5. Message Encapsulation . . . . . . . . . . . . . . . . . . . . 11
5.1. Encapsulation Formats . . . . . . . . . . . . . . . . . . 11
5.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Application Hints Extensions . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
Ott, et al. Expires May 15, 2008 [Page 2]
Internet-Draft Application Conventions November 2007
1. Introduction
Communications using the bundle protocol specification [2] has so far
mostly been carried out in rather closed environments. That is,
bundle agents have typically been handling messages from either a
single type of application or from multiple applications developed in
a coordinated fashion. Common usage conventions for the URIs for
endpoint identification and bundle routing are not an issue in such
environments. Recent research, however, has suggested the use of
Delay-tolerant Networking based upon the DTNRG architecture [6] for a
number of open applications to be run across the Internet or
connected to the Internet, suggesting the use of DTN for addressing
basic communication needs in remote areas and in support of mobility.
In this context, various application layer protocols from the
Internet realm have been adapted for transmission over the bundle
protocol, most notably email and HTTP, with further protocols under
investigation.
Building upon some of the thoughts put forward in [12], this document
identifies some further issues requiring consideration when moving
from the aforementioned "closed" DTN operation to an open environment
and suggests usage conventions for the URIs for endpoint
identification and bundle routing that allow arbitrary applications
to co-exist in a shared DTN environment. In addition, this document
proposes an---initially experimental---extension to the bundle
protocol header in support of application-specific functions.
This document is based upon experience gained from using and
extending the DTN reference implementation, expanding on it, and
writing prototype applications and protocol encapsulations. Our
experience is based upon supporting delay-tolerant interpersonal
communications; other application scenarios will bring along further
and possibly different requirements and observations. Comments and
additions are solicited to create a more comprehensive view of the
problems at hand when moving from closed to open deployments of DTNs.
For draft specifications in this document, the keywords MUST, SHOULD,
and MAY as defined in RFC 2119 [1] apply.
Ott, et al. Expires May 15, 2008 [Page 3]
Internet-Draft Application Conventions November 2007
2. DTN Operation in an Open Environment
When running DTN applications in the open Internet, and ultimately at
large scale, bundle routers form a DTN overlay of some sort (which
may go well beyond the 'borders' of the Internet of today). If
arbitrary applications are run in such an environment, it is
necessary that (see also [12]):
o different types of applications choose their endpoint identifiers
(EIDs) from disjoint namespaces so that different application
instances do not accidentally collide with one another;
o different applications of the same type choose their EIDs from the
same namespace but still ensure that these are unique and allow
for adequate multiplexing within the application class where
necessary;
o bundle agents cooperating to serve multiple applications agree on
a set of rules for routing based upon EIDs so that bundles are
forwarded to their respective destinations; and
o the usage of EIDs across the DTN allows for efficient routing
protocols if dynamic exchange of routing information is deemed
necessary (how to exchange the routing information is yet another
aspect).
This calls for common usage conventions for the URIs for endpoint
identification and bundle routing. The basic URI conventions are
addressed in section 3, discussions on routing will be captured in
section 4 (to be expanded further in a future revision of this
document).
Furthermore, per-application conventions should be provided that
specify how application protocol messages are encapsulated in
bundles. In general, this may include
o message encoding rules,
o how to delineate messages (if stacking multiple messages is
allowed in the same bundle),
o specifying the message and content type,
o possibly specifying rules for (reactive) fragmentation,
o the utilization of bundle-layer mechanisms (such as end-to-end
delivery confirmations), and
Ott, et al. Expires May 15, 2008 [Page 4]
Internet-Draft Application Conventions November 2007
o possibly transfer-encodings and other operations (such as
compression of the message contents).
To a certain extent, guidelines---somewhat similar to those specified
for writers of RTP payload types [8] [13]---are conceivable. Such a
set of encapsulation rules for text-based Internet application
protocols is addressed in section 5.
Finally, bundle routing and forwarding schemes may benefit from
understanding, at an abstract level, the application and message type
of a particular message. Depending on the URI conventions used, some
of this information may already be extracted from the EID. In order
to decouple endpoint addressing from application-independent bundle
contents identification, we suggest an extension block for the bundle
protocol that captures common information about the bundle contents.
This is specified in section 6.
Ott, et al. Expires May 15, 2008 [Page 5]
Internet-Draft Application Conventions November 2007
3. Conventions for DTN EIDs
Endpoint identifiers (EIDs) are used to denote individual endpoints
(singletons) or groups of endpoints. They serve as the primary point
for routing/forwarding towards a (set of) physical/logical node(s) as
well as for demultiplexing different applications running on a single
node. EIDs are defined to be Unique Resource Identifiers (URIs) and
thus comprise a 'scheme' and a 'scheme-specific part' (SSP), all
text-encoded and separated by the colon (':') character [2].
Some considerations on EIDs have been raised in [12] which explains a
lot of the open issues with EIDs. This document expands on these
with some concrete proposals.
Currently, one URI scheme for DTNs ('dtn:') is suggested with no
explicit substructure defined for the SSP. Only 'dtn:none' is
defined [2]. However, the DTN reference implementation uses a
structure of 'dtn:<node-id>/<application-id>' which has been
described in earlier versions of the bundle protocol specification.
To perform demultiplexing across different applications, the
respective application-specific URI schemes MUST be used, e.g.,
o 'mailto:' to identify senders and receivers of email messages
encapsulated in bundles
o 'http:' to identify HTTP traffic
o 'ftp:' to denote file transfer operations
This is in contrast to an earlier proposal contained in the bundle
specification about using suffixes of the EID to denote individual
applications (which is still, however, one of the practices supported
in the DTN reference implementation).
The demultiplexing beyond the application protocol is not defined in
this document and is considered to be application-specific. However,
note that some guidelines are necessary which deserve common
discussion:
o For many applications, well-known addresses used to contact a
server or peer instance on a particular node (the "listening EID")
may need to be distinguished from application instances initiating
outgoing communications (the latter of which may be assigned
"dynamic EIDs") so that multiple instances of an application can
be instantiated on a node. One simple approach would be to use a
base EID for the well-known address and append application-
specific instance numbers (as has been done in the DTN reference
Ott, et al. Expires May 15, 2008 [Page 6]
Internet-Draft Application Conventions November 2007
implementation and for various applications). For applications
that do not perform a specific registrations when initiating
communications to a peer randomly assigned identifiers could be
used.
o Whenever one DTN endpoint acts as a representative for multiple
others, discussion is needed if and how a differentiation between
the final target and its representative shall take place. One
example are email message stores (servers) which maintain messages
for a set of users: for (interactive) access and/or for backup
purposes. Another one is the case of communication between DTN
realms and applications in the Internet, e.g., via DTN-to-Internet
gateways as have been designed for email.
Another interesting aspect is how much application context an EID
should include. Two basic options are conceivable:
o The EID includes only sufficient information to identify the
application entity itself while application-specific information
is not part of the EID. For an HTTP URI, this would mean that the
HTTP URI does not contain a local resource (but simply
http://hostname/). It needs to be verified that such reductions
are allowed in the respective URI formats.
o The EID includes additional information about the local resource
and the respective application entity is found by means of (local)
prefix or suffix matching. For an HTTP URI, this would mean that
the complete resource URI is included (http://hostname/path).
Particularly in this case, wildcard matching for routing and
forwarding as well as for registrations is required to allow
"server applications" to easily take responsibility for a large
set of resources.
Combinations are also possible. On the one hand, allowing further
demultiplexing information in the EID may simplify application-
specific processing as no further intra-application demultiplexing
points are needed and load balancing across multiple instances of the
same application may be simplified. On the other hand, disallowing
demultiplexing may simplify aggregation of routing information.
However, it should be considered that, unlike the current Internet,
DTNs may not use routing schemes that benefit from hierarchical
structures and URIs (e.g., those belonging to users such as mailto:
URIs) may not be singletons as they have been in the traditional
Internet.
Further considerations on routing using different EID schemes are
given in the next section.
Ott, et al. Expires May 15, 2008 [Page 7]
Internet-Draft Application Conventions November 2007
4. Routing conventions and EIDs
At this point, this document restricts itself to outlining the
options for DTN routing based upon EIDs to stimulate discussion.
Future revisions will incorporate findinds from such discussions and
give recommendations on how DTN routing protocols should be defined
to make use of EIDs.
Basically, there are several alternatives for DTN routing protocols:
a. Routing protocols may treat EIDs as opaque strings without any
substructure and perform forwarding decisions only upon full
matches.
b. Routing protocols may treat EIDs as opaque strings without any
substructure but assume significance to decrease from left to
right. In such a case, they may perform forwarding decisions
based upon longest prefix matches.
c. Routing protocols may utilize the URI structure of EIDs being
composed of a 'scheme' and a 'scheme-specific part' (SSP). They
may choose to route independent of the respective scheme and
treat the SSP either as an opaque string and perform routing as
per (a) or (b) on the SSP.
d. Like (c), however, routing may be dependent on the respective
scheme. The forwarding decision may treat the scheme as more
important than the SSP (and, e.g., choose the forwarding table
based upon the scheme) or less important (and, e.g., take only
scheduling or load balancing decisions based upont the scheme).
In either case, the SSP may be treated as an opaque string and
perform routing as per (a) or (b) on the SSP.
e. Like (c) and (d), however, the scheme-specific part is treated as
having a substructure composed of one part (A) denoting a host or
a topologically or administratively significant entity to be
exploited for routing purposes and another part (B) identifying a
sub-entity within the former. In the traditional Internet, this
would be an IP address (A) and a port number (B). For HTTP URIs,
this would be a "hostport" part identifying the server (A) and
the identifier for the local resource (B). For mailto and other
URIs identifying users, this would be the user identifier (B) and
a host/domain name (A), with the sequence being reversed. In
these cases, a hierarchical routing may be applied that first
tries to route towards the (physical) entity (e.g., a host) using
(c) or (d) on part (A) but does not consider part (B) for
'global' forwarding. Part (B) will only be considered for
'local' delivery.
Ott, et al. Expires May 15, 2008 [Page 8]
Internet-Draft Application Conventions November 2007
f. Within part (A) identified in (e), some further substructure may
be considerd, e.g., following a hierarchy similar to the DNS (but
not necessarily resolvable via DNS). If some substructure is
assumed, further hierarchical routing and route aggregation are
possible. It should be noted that, with current practice in the
DTN URI scheme, such a hierarchy may be present but does not map
to the DNS and hence cannot be used to resolve DTN URIs into
specific bundle routers. For specific URI schemes, such a
mapping may be specified at some point; however, in general, no
such mapping can be assumed.
g. Finally, some form of wildcard or full regular expression-based
matching could be applied to the entire EID (and thus,
implicitly, also separately to both parts (A) and (B)) to allow
for utmost flexibility.
Obviously, the definition of URI conventions from section 3 and the
routing/forwarding conventions specified in section 5 require some
degree of coordination.
In particular, when allowing for arbitrary URI schemes, hierarchical
routing may only be possible if the URI schemes are understood by all
bundle agents. This requires careful definition of the routing
conventions to maintain extensibility towards future URI schemes.
Two simple examples of different ordering of hierarchies:
mailto:jo@example.com
http://www.example.com/~jo/
Unless a well-known (at the time of the initial specification) scheme
is used, an EID could explicitly indicate whether prefix matching
should be done from left to right or from the right to the left and
which parts should be considered. This is depicted in figure 1:
<scheme>:<scheme-specific-part>
^ ^ ^
|---- A ----|--- B ---|
^ ^
| |
start-offset |
end-offset
Figure 1: Indicating forwarding-relevant information in an EID
Ott, et al. Expires May 15, 2008 [Page 9]
Internet-Draft Application Conventions November 2007
For this purpose, three additional fields (optional) would be
required (operating on octets):
o start-offset for the 'routable part' of the EID>
o end-offset for the 'routable part' of the EID
o matching-flag: indicates 'FULL', 'LP', or 'LS' to denote the type
of matching (full, longest-prefix, or longest-suffix')
Recent experience when using the DTN reference implementation for
realizing an email gateway confirms the need for conventions to
handle routing based upon EIDs. In the specific case, the DTN
reference implementation interprets mailto URIs (mailto:user@domain)
and disregards the part left of the '@' sign (i.e., the user) for
routing. While this supports efficient routing towards a
representative mail server (as discussed above), it prohibits user-
specific routing based upon the full EID in ad-hoc networks. An
explicit expression of how the respective EID is to be treated
internally by intermediate nodes hence is advisable. Proper hints
should ideally allow for both delivery to individual users as well as
delivery via representatives.
A precise specification and more detailed recommendations are left
for further study after agreement on the basics has been reached.
Ott, et al. Expires May 15, 2008 [Page 10]
Internet-Draft Application Conventions November 2007
5. Message Encapsulation
Basically, the aforementioned definition of a demultiplexing scheme
for bundles based upon the (DTN) URI is sufficient for disambiguating
bundles targeted at different applications. However, numerous (text-
based) protocols in the Internet follow common conventions, such as
using RFC2822-style headers and MIME encapsulation, which provide the
benefit of code re-use across different applications. Therefore, it
may be worthwhile discussing these conventions and defining a common
encapsulation format for this class of applications. Currently, the
set of text-based application protocols making use of similar message
structures include (but are not limited to): electronic mail [3],
HTTP [10], RTSP [9], and SIP [11]. Furthermore, numerous XML-based
protocols (such as Jabber) could potentially benefit from a common
encapsulation format.
The text-based protocols following the RFC2822 conventions usually
consist of three parts: a start line, a sequence of message headers,
and an optional message body. The message headers are subdivided
into protocol header pertaining to the application protocol and
entity headers describing the message body. The message body MAY be
further encapsulated using the Multipurpose Internet Mail Extensions
(MIME) [RFC2045, RFC2046] and MAY comprise multiple parts (using MIME
multipart).
Other protocols are for further study.
5.1. Encapsulation Formats
The message body of a text-based message following one of the
aforementioned protocols is usually identified by means of the
Content-Type: entity header, but similar media type definitions also
exist for the entire messages, e.g., message/rfc822, message/http,
message/sip [http://www.iana.org/assignments/media-types/message/].
This leads to three alternatives for message encapsulation:
1. The application message is placed into the DTN bundle without
further designation or encapsulation. In this case, the bundle
content is implied from the EID and no further designation is
provided.
Ott, et al. Expires May 15, 2008 [Page 11]
Internet-Draft Application Conventions November 2007
Example:
[Primary bundle block]
[Bundle payload block
HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 13
Hello, world
]
2. The application message is encapsulated in a MIME envelope which
includes an explicit Content-Type denoting the message contents
as well as possibly other parameters (such as content transfer
encoding). This supports including additional entity headers in
the MIME envelope.
Example:
[Primary bundle block]
[Bundle payload block
Content-Type: message/http
Content-Length: ...
HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 13
Hello, world
]
3. The message is encapsulated without the 'overhead' of a text-
encoded MIME header but a separate header extension block is
provided to include a content designation if desired. This field
could simply indicate a MIME type (thus sharing the same
registry), which may be preferred over setting up and maintaining
yet another content registry. Optionally, additional MIME
attributes might be included (is there value?). Protocols will
be expected to specify default content types in which case this
block would not need to be included, thus avoiding overhead for
the default operation.
Ott, et al. Expires May 15, 2008 [Page 12]
Internet-Draft Application Conventions November 2007
Example:
[Primary bundle block]
[Bundle payload identification block
content-type: message/http]
[Bundle payload block
Content-Type: message/http
Content-Length: ...
HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 13
Hello, world
]
Approach (1) is the simpler message encapsulation with less overhead
and leads to slightly easier processing. However, it also precludes
further operations such as encryption, authentication, or compression
of the complete message. If such mechanisms were to be applied, the
EIDs need to be used for demultiplexing (just as different port
numbers are used for HTTP and HTTPS).
Approach (2) incurs more overhead (some 50 bytes minimum) but
provides explicit content description and thus allows for
demultiplexing different message formats.
Approach (3) incurs less overhead than (2) while maintaining the
explicit content description and thus allows for demultiplexing
different message formats.
Allowing multiple encapsulation formats, however, may increase the
risk of non-interoperability (e.g., if a sender is not aware that the
transfer encoding or compression used is not understood by the
receiver). Such issues may be expensive or impossible to repair in
DTN environments due to the potentially limited degree of
interactivity. Application protocol encapsulation specifications
would need to clearly address these issues and define mandatory to
implement formats.
If the message content format shall be made explicit, as per (3), a
dedicated extension block could also be used for this purpose
(expanding further on the one proposed in section 6). The pros and
cons of replicating such a description at the DTN layer will have to
be investigated, depending on how many parameters will be needed to
fully describe the bundle contents adequately.
In either case, allowing for an explicit identification of the
Ott, et al. Expires May 15, 2008 [Page 13]
Internet-Draft Application Conventions November 2007
respective contents will enable distinguishing between a single
contained resource and set of aggregated resources (using, e.g.,
multipart/mixed or multipart/related), e.g., multiple objects
required to display a web page [7].
An open question is whether such a multiplexing of multiple closely
related resources should happen within a single bundle payload,
should occur by combining multiple payload blocks or bundles, or
simply by using a batch of otherwise unrelated bundles. Or such a
decision could be left entirely to the application-specific payload
definition.
5.2. Security
Application protocols communicating via the bundle protocol may make
use of the bundle security mechanisms (e.g., for end-to-end
protection). In some cases, however, it may be desirable to maintain
the application layer security properties (e.g., a signature on a
piece of contents) beyond the bundle transmission and reception
process. In such cases, security mechanisms should be applied above
the bundle layer and attached to the payloads rather than to the
encapsulating bundle protocols.
For the protocols described above, one viable option is using S/MIME
[4] [5] as lasting encapsulation format. Depending on the intended
semantics, either the entire application message or just the message
body may be protected.
Note that for optionally protecting the entire application message,
one of the enhanced encapsulation formats (2) or (3) from section 5.1
needs to be used.
Ott, et al. Expires May 15, 2008 [Page 14]
Internet-Draft Application Conventions November 2007
6. Application Hints Extensions
As bundle agents store, possibly carry, and forward bundles from
different applications, the nodes may carry these bundles for an
extended period of time. In environments with frequent
disconnections (and possibly short connectivity times), significant
queues may build up in a bundle agent that may not be easily worked
off during a single or a contact or contact time. This requires
o a bundle agent to drop queued bundles if new ones come in,
o scheduling bundles for (re-)transmission to the next contact, and
o decide for which bundles to accept custody.
These decisions are taken in conjunction with the specific routing
protocols and forwarding algorithms in use: these may demand
replicating a bundle a certain number of times or transmitting it
just once, determine to which contact(s) to forward a bundle, and
define the order of deletion (e.g., earliest vs. latest expiry time,
size-based). For infrastructure nodes dealing with random bundles or
in closed environments with more or less 'equal' bundles, such
mechanisms---as they should typically also be applied in IP
networks---are just fine.
This neutral treatment can be questioned, however, when dealing with
personal mobile devices running heterogenenous applications for two
reasons:
o Mobile nodes may prefer to utilize local resources (power, CPU,
memory) for bundles from those applications they are running by
themselves. Similarly, requests and responses for application
protocols may be treated differently. Both parameters could be
made explicit in a block header.
o Beyond this, mobile devices may improve their service quality
(e.g., response time, request completion probability) by employing
cooperative caching mechanisms that leverage messages stored in
bundle agents [OP2006]. For this purpose, a bundle agent would
benefit from an identification of the resource contained in the
bundle and its 'cache lifetime' (rather than its bundle lifetime).
To allow for such application-aware processing, the following
extension block ("Application-Hints") is defined. (Note that
draft-symington-dtnrg-bundle-metadata-block-00 defines a related
metadata block, which is rather complementary as it describes a
bundle while the Application-Hints defined below identifies a bundle
and its properties.)
Ott, et al. Expires May 15, 2008 [Page 15]
Internet-Draft Application Conventions November 2007
+----------------+----------------+----------------+----------------+
| Block type | Flags | Block length |
+----------------+----------------+----------------+----------------+
| Resource Hash (0 if unused) |
+----------------+----------------+----------------+----------------+
| Application Layer Lifetime |
+----------------+----------------+----------------+----------------+
| OpType | ApplProtLength |ResourceIdLength| ExtensionLength|
+----------------+----------------+----------------+----------------+
| Application protocol id (e.g., http) |
+----------------+----------------+----------------+----------------+
| Resource identifier, in UTF-8 |
: (e.g., http://www.dtnrg.org/index.html) :
| |
+----------------+----------------+----------------+----------------+
The Block type value for the Application Hints block is TBD.
The Flags fields specifies the Block processing fields are per
section 4.3 of the bundle protocol specification [2]. The flags MUST
be set as follows:
0 - TRUE. Block must be replicated in every fragment.
1 - FALSE. Transmit status report if block can't be processed.
2 - FALSE. Delete bundle if block can't be processed.
3 - As appropriate. Last block.
4 - FALSE. Discard block if it can't be processed.
5 - As appropriate. Block was forwarded without being processed.
Should initially be set to FALSE.
6 - FALSE. Block contains an EID-reference field.
Block length: This field specifies the length of the block. This is
an SDNV and is represented as a 16-bit value only for convenience of
the presentation.
Resource hash: A SHA-1 hash of the resource contained (if any)
excluding all headers to allow for efficient comparison.
The Application Layer Lifetime includes the validity of the resource
(if any) using the same format as the bundle protocol. A value of
zero specifies that the lifetime is unknown. This is an SDNV and is
shown in the above figure as a 32-bit value only for convenience of
the presentation.
The OpType is an 8-bit field indicating the application-specific
operation type. The MSB indicates whether or not a resource is
Ott, et al. Expires May 15, 2008 [Page 16]
Internet-Draft Application Conventions November 2007
included in the bundle. The following values are defined:
0x00 - Unknown / other / not specified, no resource included
0x80 - Unknown / other / not specified, resource included
0x01 - Request, no resource included
0x81 - Request, resource included
0x02 - Response, no rescource included
0x82 - Response, rescource included
0x03 - Unconfirmed event, no resource included
0x83 - Unconfirmed event, resource included
Further values are to be defined. The hint whether or not a resource
is included shall give an indication to an intermediate bundle agent
about the potential 'value' of this bundle.
The ApplProtLength indicates the length of the included application
protocol identifier. A value of zero indicates that no protocol
identifier is present. This is an SDNV and is represented as an
8-bit value only for convenience of the presentation.
The ResourceLength indicates the length of the included resource
value (e.g., an application-layer message id or an HTTP URI). A
value of zero indicates that no resource identifier is present. This
is an SDNV and is represented as an 8-bit value only for convenience
of the presentation.
The ExtensionLength indicates the length of an extension following
the resource identifier. Details TBD. A value of zero indicates
that no extension is present. This is an SDNV and is represented as
an 8-bit value only for convenience of the presentation.
The application protocol id field is used to encode the protocol as a
URI scheme. The resource should be a full URI or URN including the
respective scheme, so that both the application protocol and the
actual resource can be derived from this field.
The Resource value field is used to encode the resource contained in
the bundle in UTF-8. The resource should be a full URI or URN
including the respective scheme, so that both the application
protocol and the actual resource can be derived from this field.
This document does not specify specific treatment of the Application-
Hints block, but rather suggests providing such hints as a means for
service differentiation in resource-constrained nodes. Drawing
conclusions for local treatment is left to the implementation. (This
entire section may ultimately be moved to a different document.)
Ott, et al. Expires May 15, 2008 [Page 17]
Internet-Draft Application Conventions November 2007
7. Security Considerations
Any kind of application-specific tagging of contents (as, e.g.,
defined in section 6) is subject to forgery. Applications may
attempt to guess for which hints they might obtain better service and
fake the field to this end. As long as intermediate nodes exhibit
heterogenous behavior (so that a malicious node cannot tell when it
may receive better service), this issue is partly mitigated.
Trustworthy identification of the sender will allow an intermediary
to decide whether to take such application-hints into account or not.
Further issues are TBD.
Ott, et al. Expires May 15, 2008 [Page 18]
Internet-Draft Application Conventions November 2007
8. References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Scott, K. and S. Burleigh, "Bundle Protocol Specification",
draft-irtf-dtnrg-bundle-spec-10 (work in progress), July 2007.
[3] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[4] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Certificate Handling", RFC 3850,
July 2004.
[5] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851,
July 2004.
[6] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R.,
Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking
Architecture", RFC 4838, April 2007.
8.2. Informative References
[7] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, "MIME
Encapsulation of Aggregate Documents, such as HTML (MHTML)",
RFC 2557, March 1999.
[8] Handley, M. and C. Perkins, "Guidelines for Writers of RTP
Payload Format Specifications", BCP 36, RFC 2736,
December 1999.
[9] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
[10] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[11] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[12] Eddy, W., "Architectural Considerations for the use of Endpoint
Identifiers in Delay Tolerant Networking",
draft-eddy-dtnrg-eid-00 (work in progress), May 2006.
Ott, et al. Expires May 15, 2008 [Page 19]
Internet-Draft Application Conventions November 2007
[13] Westerlund, M., "How to Write an RTP Payload Format",
draft-ietf-avt-rtp-howto-02 (work in progress), July 2007.
Ott, et al. Expires May 15, 2008 [Page 20]
Internet-Draft Application Conventions November 2007
Authors' Addresses
Joerg Ott
TKK Netlab
Otakaari 5A
Espoo 02150
Finland
Teemu Kaerkkaeinen
TKK Netlab
Otakaari 5A
Espoo 02150
Finland
Mikko Juhani Pitkaenen
Helsinki Institute of Physics (HIP) Technology Programme
Ott, et al. Expires May 15, 2008 [Page 21]
Internet-Draft Application Conventions November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Ott, et al. Expires May 15, 2008 [Page 22]