[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/