[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
INTERNET-DRAFT                             Henrik Frystyk Nielsen
draft-nielsen-dime-02                      Henry Sanders
                                           Microsoft,
                                           Russell Butek
                                           Simon Nash
                                           IBM

Expires December 2002                      June 17, 2002

                Direct Internet Message Encapsulation (DIME)


Status of this Memo


     This document is an Internet-Draft and is subject to all provisions
     of Section 10 of RFC2026.


     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".


     Please send comments to the "dime@discuss.develop.com" mailing
     list, which is archived at "http://discuss.develop.com/dime.html".


Abstract


     Direct Internet Message Encapsulation (DIME) is a lightweight,
     binary message format that can be used to encapsulate one or more
     application-defined payloads of arbitrary type and size into a
     single message construct. Each payload is described by a type, a
     length, and an optional identifier. Both URIs and MIME media type
     constructs are supported as type identifiers. The payload length is
     an integer indicating the number of octets of the payload. The

Nielsen, et al.                                               [Page 1]


INTERNET-DRAFT                     DIME                     June, 2002

     optional payload identifier is a URI enabling cross-referencing
     between payloads. DIME payloads may include nested DIME messages or
     chains of linked chunks of unknown length at the time the data is
     generated. DIME is strictly a message format: it provides no
     concept of a connection or of a logical circuit, nor does it
     address head-of-line problems.


Table of Contents

     1  Introduction................................................3
     1.1   Notational Conventions...................................4
     1.2   Conformance Requirement..................................4
     1.3   Design Goals.............................................4
     1.4   DIME Terminology.........................................5
     1.5   Intended Usage...........................................7
     2  The DIME Mechanisms.........................................8
     2.1   DIME Encapsulation Constructs............................8
     2.1.1   Message................................................8
     2.1.2   Record.................................................9
     2.1.3   Record Chunks..........................................9
     2.2   DIME Version Number.....................................10
     2.3   DIME Payload Description................................10
     2.3.1   Payload Length........................................10
     2.3.2   Payload Type..........................................11
     2.3.3   Payload Identification................................12
     2.4   DIME Options............................................12
     3  The DIME Specifications....................................13
     3.1   Data Transmission Order.................................13
     3.2   Record Layout...........................................14
     3.2.1   Version...............................................15
     3.2.2   MB (Message Begin)....................................15
     3.2.3   ME (Message End)......................................15
     3.2.4   CF (Chunk Flag).......................................15
     3.2.5   TYPE_T................................................15
     3.2.6   RESRVD................................................17
     3.2.7   OPTIONS_LENGTH........................................17
     3.2.8   ID_LENGTH.............................................17
     3.2.9   TYPE_LENGTH...........................................17
     3.2.10  DATA_LENGTH...........................................17
     3.2.11  OPTIONS...............................................18
     3.2.12  ID....................................................18
     3.2.13  TYPE..................................................19
     3.2.14  DATA..................................................19
     3.3   Use of URIs in DIME.....................................20
     4  Internationalization Considerations........................20
     5  Security Considerations....................................21
     6  IANA Considerations........................................21
     6.1   Media Type Registration: application/dime...............21
     6.2   Guidelines for Registration of DIME Option Element Types23
     7  Intellectual Property......................................24
     8  Acknowledgements...........................................24
     9  References.................................................24
     10 Authors' Addresses.........................................26

Nielsen, et al.                                               [Page 2]


INTERNET-DRAFT                     DIME                     June, 2002



1  Introduction


     Direct Internet Message Encapsulation (DIME) is a lightweight,
     binary message format designed to encapsulate one or more
     application-defined payloads into a single message construct. A
     DIME message contains one or more DIME records each carrying a
     payload of arbitrary type and up to 2^32-1 octets in size. Records
     can be chained together to support larger payloads. A DIME record
     carries three parameters for describing its payload: the payload
     length, the payload type, and an optional payload identifier. The
     purpose of these parameters is as follows:


     The payload length


          The payload length indicates the number of octets in the
          payload (see section 2.3.1). By providing the payload length
          within the first 12 octets of a record, efficient record
          boundary detection is possible.


     The payload type


          The DIME payload type identifier indicates the type of the
          payload. DIME supports both URIs [10] as well as MIME media
          type constructs [7] as type identifiers (see section 2.3.2).
          By indicating the type of a payload, it is possible to
          dispatch the payload to the appropriate user application.


     The payload identifier


          A payload may be given an optional identifier in the form of
          an absolute or relative URI (see section 2.3.3). The use of an
          identifier enables payloads that support URI linking
          technologies to cross-reference other payloads.


     In addition, each record contains a version number (see section
     2.2) and a slot for optional data in the form of option elements
     (see section 2.4).








Nielsen, et al.                                               [Page 3]


INTERNET-DRAFT                     DIME                     June, 2002

1.1  Notational Conventions


     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 RFC 2119 [9].


1.2  Conformance Requirement


     An implementation is not DIME compliant if it fails to satisfy one
     or more of the MUST or REQUIRED level requirements defined in this
     specification. A DIME implementation MUST be conformant in order to
     parse or generate a DIME message defined by this specification.


1.3  Design Goals


     Because of the large number of existing message encapsulation
     formats, record marking protocols and multiplexing protocols, it is
     best to be explicit about the design goals of DIME and, in
     particular, about what is outside the scope of DIME.


     The design goal of DIME is to provide an efficient and simple
     message format that can accommodate the following:


     1.   Encapsulating arbitrary documents and entities, including
          encrypted data, XML documents, XML fragments, image data like
          GIF and JPEG files, etc.


     2.   Encapsulating documents and entities initially of unknown
          size. This capability can be used to encapsulate dynamically
          generated content or very large entities as a series of
          chunks.


     3.   Aggregating multiple documents and entities that are logically
          associated in some manner into a single message. For example,
          DIME can be used to encapsulate a SOAP message and a set of
          attachments referenced from that SOAP message.


     In order to achieve efficiency and simplicity, the mechanisms
     provided by this specification have been deliberately limited to
     serve these purposes. DIME has not been designed as a general
     message description or document format such as MIME or XML.
     Instead, DIME-based applications can take advantage of such formats
     by encapsulating them in DIME messages.


Nielsen, et al.                                               [Page 4]


INTERNET-DRAFT                     DIME                     June, 2002

     The following list identifies what is outside the scope of DIME:


     1.   DIME does not make any assumptions about the types of payloads
          that are carried within DIME messages or about the message
          exchange patterns of such messages.


     2.   DIME does not in any way introduce the notion of a connection
          or of a logical circuit (virtual or otherwise).


     3.   DIME does not attempt to deal with head-of-line blocking
          problems that might occur when using stream-oriented protocols
          like TCP.


1.4  DIME Terminology


     DIME message


          The basic message construct defined by this specification. A
          DIME message contains one or more DIME records (see section
          2.1.1).


     DIME record


          A DIME record contains a payload described by a type, a
          length, and an optional identifier (see section 2.1.2).


     DIME record chunk


          A DIME record that has been marked as containing a chunk of a
          payload rather than a full payload (see section 2.1.3).


     DIME version


          A number used to identify the format of a DIME record (see
          section 2.2).


     DIME payload


          The data carried within a DIME record defined by a user
          application.

Nielsen, et al.                                               [Page 5]


INTERNET-DRAFT                     DIME                     June, 2002

     DIME chunked payload


          A payload that has been partitioned into multiple DIME record
          chunks. This can be used to carry dynamically generated
          content or very large entities that don't fit into a single
          DIME record (see section 2.1.3).


     DIME payload length


          The size of the payload indicated in number of octets (see
          section 2.3.1).


     DIME payload type


          An identifier that indicates the type of the payload. This
          specification supports both URIs [10] as well as MIME media
          type constructs [11] as type identifiers (see section 2.3.2).


     DIME payload identifier


          A URI that optionally can be used to identify a payload (see
          section 2.3.3).


     DIME options


          A DIME record might contain zero or more optional pieces of
          data in the form of DIME option elements. This can be used to
          carry additional information about the payload or information
          which otherwise may be of benefit to the DIME parser parsing
          the DIME message (see section 2.4).


     DIME option element


          An optional piece of data that may be carried in a DIME record
          as part of the DIME options (see section 2.4).


     DIME user application


          The logical, higher-layer application that uses DIME for
          encapsulating messages.


Nielsen, et al.                                               [Page 6]


INTERNET-DRAFT                     DIME                     June, 2002

     DIME generator


          An entity or module that encapsulates user application-defined
          payloads within DIME messages.


     DIME parser


          An entity or module that parses DIME messages and hands off
          the payloads to a DIME user application.


1.5  Intended Usage


     The intended usage of DIME is as follows: A user application wants
     to encapsulate one or more related documents into a single DIME
     message. For example, this can be a SOAP message along with a set
     of attachments. The DIME generator encapsulates each document in
     DIME records as payload or chunked payload, indicating the type and
     length of the payload along with an optional identifier. The DIME
     records are then put together to form a single DIME message. The
     DIME parser deconstructs the DIME message and hands the payloads to
     a (potentially different) user application.


     DIME can be used in combination with most protocols that support
     the exchange of binary data as long as the DIME message can be
     exchanged in its entirety. A DIME message can be carried as a MIME
     entity using the media type "application/dime" (see section 6 for
     IANA media type registration of "application/dime").


     DIME records can encapsulate documents of any type. It is possible
     to carry MIME messages in DIME records by using a media type such
     as "message/rfc822". A DIME message can be encapsulated in a DIME
     record by using the media type "application/dime" (see section 6).


     It is important to note that although MIME entities are supported,
     there are no assumptions in DIME that a record payload is MIME;
     DIME makes no assumption concerning the type of the payloads
     carried in a DIME message.


     DIME provides no support for error handling. It is up to the DIME
     parser to determine the implications of receiving a malformed DIME
     message not conforming to this specification (see section 2.2 for a
     description of DIME version numbers). It is the responsibility of
     the user applications involved to provide any additional
     functionality such as QoS that they may need as part of the overall
     system in which they participate.

Nielsen, et al.                                               [Page 7]


INTERNET-DRAFT                     DIME                     June, 2002

2  The DIME Mechanisms


     This section describes the mechanisms used in DIME. The specific
     syntax for these mechanisms is defined in section 3.


2.1  DIME Encapsulation Constructs


2.1.1 Message


     A DIME message is composed of one or more DIME records. The first
     record in a message is marked with the MB (Message Begin) flag set
     and the last record in the message is marked with the ME (Message
     End) flag set (see section 3.2.1 and 3.2.3). The minimum message
     length is one record which is achieved by setting both the MB and
     the ME flag in the same record. Note that at least two record
     chunks are required in order to encode a chunked payload (see
     section 2.1.3). The maximum number of DIME records that can be
     carried in a DIME message is unbounded.


     DIME messages MUST NOT overlap; that is, the MB and the ME flags
     MUST NOT be used to nest DIME messages. DIME messages can be nested
     by carrying a full DIME message within a DIME record with the type
     "application/dime" (see section 6).


     <--------------------- DIME message ---------------------->
     +---------+     +---------+     +---------+     +---------+
     | R1 MB=1 | ... | Rr      | ... | Rs      | ... | Rt ME=1 |
     +---------+     +---------+     +---------+     +---------+


        Figure 1: Example of a DIME message with a set of records.
        The message head is to the left and the tail to the right,
        with the logical record indexes t > s > r > 1. The MB
        (Message Begin) flag is set in the first record (index 1)
        and the ME (Message End) flag is set in the last record
        (index t).


     Note that actual DIME records do not carry an index number; the
     ordering is implicitly given by the order in which the records are
     serialized.








Nielsen, et al.                                               [Page 8]


INTERNET-DRAFT                     DIME                     June, 2002

2.1.2 Record


     A record is the unit for carrying a payload within a DIME message.
     Each payload is described by its own set of parameters (see section
     2.3).


2.1.3 Record Chunks


     A record chunk is a DIME record that contains a chunk of a payload.
     Chunked payloads can be used to partition dynamically generated
     content or very large entities into multiple subsequent record
     chunks serialized within the same DIME message.


     Chunking is not a mechanism for introducing multiplexing into DIME.
     It is a mechanism to limit the need for outbound buffering on the
     generating side. This is similar to the message chunking mechanism
     defined in HTTP/1.1 [11].


     A DIME message can contain zero or more chunked payloads. A chunked
     payload is encoded as an initial record chunk followed by zero or
     more middle record chunks followed by a terminating record chunk.
     Each record chunk is encoded using the following encoding rules:


     1.   The initial record chunk is a DIME record with the CF (Chunk
          Flag) flag set (see section 3.2.4). The type of the entire
          chunked payload MUST be indicated in the TYPE field regardless
          of whether the DATA_LENGTH field value is zero or not. The ID
          field MAY be used to carry an identifier of the entire chunked
          payload. The DATA_LENGTH field indicates the size of the data
          carried in the DATA field (see section 2.3.1).


     2.   Each middle record chunk is a DIME record with the CF flag set
          indicating that this record chunk contains the next chunk of
          data of the same type and with the same identifier as the
          initial record chunk. The value of the TYPE_LENGTH and the
          ID_LENGTH fields MUST be zero and the TYPE_T field value MUST
          be 0x00 (see section 3.2.8). The DATA_LENGTH field indicates
          the size of the data carried in the DATA field (see section
          2.3.1).


     3.   The terminating record chunk is a DIME record with the CF flag
          cleared indicating that this record chunk contains the last
          chunk of data of the same type and with the same identifier as
          the initial record chunk. As with the middle record chunks,
          the value of the TYPE_LENGTH and the ID_LENGTH fields MUST be
          zero and the TYPE_T field value MUST be 0x00 (see section

Nielsen, et al.                                               [Page 9]


INTERNET-DRAFT                     DIME                     June, 2002

          3.2.8). The DATA_LENGTH field indicates the size of the data
          carried in DATA field (see section 2.3.1).


     A chunked payload MUST be entirely encapsulated within a single
     DIME message. That is, a chunked payload MUST NOT span multiple
     DIME messages. As a result, neither an initial nor a middle record
     chunk can have the ME (Message End) flag set.


2.2  DIME Version Number


     A DIME record contains a version number that indicates the format
     of the record. The DIME version number is incremented when the
     format of a DIME message is changed. Version numbers are considered
     to be "major" rather than "minor". That is, there is no assumption
     of compatibility between any two versions.


     All DIME records in a DIME message including record chunks MUST be
     of the same version. A DIME parser encountering different DIME
     version numbers in different DIME records in the same DIME message
     MUST discard that message as faulty.


     In order to parse a DIME record of a given version, a DIME parser
     MUST be compliant with that version (see section 1.2). A DIME
     implementation MUST NOT attempt to parse or generate a DIME record
     with a version that the implementation does not comply with. A DIME
     implementation MAY but NEED NOT support multiple DIME versions.


     This document defines version 1 (0x01) (see section 3.2.1). Any new
     version of DIME MUST be published as a standard-track RFC following
     IETF consensus.


2.3  DIME Payload Description


     Each record contains information about the payload carried within
     it. This section introduces the mechanisms by which these payloads
     are described.


2.3.1 Payload Length


     Regardless of the relationship of a record to other records, the
     payload length always indicates the length of the payload
     encapsulated in THIS record. The length of the payload is indicated
     in number of octets in the DATA_LENGTH field (see section 3.2.10).
     Note that zero is a valid length.

Nielsen, et al.                                              [Page 10]


INTERNET-DRAFT                     DIME                     June, 2002

2.3.2 Payload Type


     The payload type of a record indicates the kind of data being
     carried in the payload of that record. This may be used to guide
     the processing of the payload at the discretion of the user
     application. The type of the first record, by convention, provides
     the processing context not only for the first record but for the
     whole DIME message. Additional context for processing the message
     may be provided by the transport service port (TCP, UDP, etc) at
     which the message was received and by other communication
     parameters.


     It is important to emphasize that DIME mandates no specific
     processing model for DIME messages. The usage of the payload types
     is entirely at the discretion of the user application. The comments
     regarding usage above should be taken as guidelines for building
     processing conventions, including mappings of higher level
     application semantics onto DIME.


     The structure and format of the TYPE field value is indicated using
     the TYPE_T field (see section 3.2.5). This specification supports
     TYPE field values in the form of absolute URIs and MIME media type
     constructs. The former allows for decentralized control of the
     value space and the latter allows DIME to take advantage of the
     already very large and successful media type value space maintained
     by IANA [3].


     The media type registration process is outlined in RFC 2048 [8].
     Use of non-registered media types is discouraged. The URI scheme
     registration process is described in RFC 2717 [13]. It is
     recommended that only well-known URI schemes registered by IANA be
     used (see [17] for a current list).


     URIs can be used for message types that are defined by URIs.
     Records that carry a payload with an XML-based message type MAY use
     the XML namespace identifier of the root element as the TYPE field
     value. A SOAP/1.1 message, for example, may be represented by the
     URI


          http://schemas.xmlsoap.org/soap/envelope/


     Records that carry a payload with an existing, registered media
     type SHOULD carry a TYPE field value of that media type. Note that
     the TYPE field indicates the type of the payload; it does NOT refer
     to a MIME message that contains an entity of the given type. For
     example, the media type


Nielsen, et al.                                              [Page 11]


INTERNET-DRAFT                     DIME                     June, 2002

          image/jpeg


     indicates that the payload is a JPEG image. Similarly, the media
     type


          message/http


     indicates that the payload is an HTTP message as defined by RFC
     2616 [11]. A value of


          application/xml; charset="utf-16"


     indicates that the payload is an XML document as defined by RFC
     3023 [16].


2.3.3 Payload Identification


     The optional payload identifier allows user applications to
     identify a payload within a DIME record. By providing a payload
     identifier, it becomes possible for other payloads supporting URI-
     based linking technologies to refer to that payload. DIME does not
     mandate any particular linking mechanism but leaves this to the
     user application to define in the language it prefers.


     It is important that payload identifiers are maintained so that
     references to those payloads are not broken. If records are
     repackaged, for example, by an intermediate application, then that
     application MUST ensure that the payload identifiers are preserved.


2.4  DIME Options


     DIME has provisions for carrying additional information in a DIME
     record as option elements. A DIME record (including a record chunk)
     can carry zero or more such option elements each containing
     information about the payload or information which otherwise may be
     of benefit to a DIME parser.


     An option element contains two parameters describing its contents:
     a type and a length. The meaning of these parameters is as follows:


     o    The option element type indicates the structure and format of
          the data carried in that element (see section 3.2.11).

Nielsen, et al.                                              [Page 12]


INTERNET-DRAFT                     DIME                     June, 2002

     o    The option element length indicates the size of the data
          carried in that element in number of octets (see section
          3.2.11).


     The structure and format of each element is entirely determined by
     the option element type. This specification does not define any
     option element types. DIME option elements are defined in a
     centralized manner controlled by IANA (see section 6.2 for IANA
     guidelines).


     Option elements are set on a per DIME record basis. A DIME
     generator MAY generate different option elements for different DIME
     records in the same DIME message. Use of option data is OPTIONAL by
     DIME generators.


     DIME option element types are defined independently of each other;
     support for an element type does not imply support for other
     element types. That is, a DIME parser that recognizes option
     element type 5 might not recognize type 4 or 6.


     A DIME parser conforming to this specification MAY but NEED NOT
     support any option element types. A DIME parser SHOULD ignore
     unrecognized option element types.


3  The DIME Specifications


3.1  Data Transmission Order


     The order of transmission of the DIME record described in this
     document is resolved to the octet level. For diagrams showing a
     group of octets, the order of transmission of those octets is first
     left to right and then top to bottom, as they are read in English.
     For example, in the diagram in Figure 2, the octets are transmitted
     in the order they are numbered.


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Octet 1    |    Octet 2    |    Octet 3    |    Octet 4    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Octet 5    |    Octet 6    |    Octet 7    |    Octet 8    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


        Figure 2: DIME octet ordering


Nielsen, et al.                                              [Page 13]


INTERNET-DRAFT                     DIME                     June, 2002

     Whenever an octet represents a numeric quantity, the leftmost bit
     in the diagram is the high order or most significant bit. That is,
     the bit labeled 0 is the most significant bit.


     For each multi-octet field representing a numeric quantity defined
     by DIME, the leftmost bit of the whole field is the most
     significant bit. Such quantities are transmitted in a big-endian
     manner with the most significant octet transmitted first.


3.2  Record Layout


     DIME records are variable length records with a common format
     illustrated in Figure 3. In the following sections, the individual
     record fields are described in more detail.


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         |M|M|C|       |       |                               |
     | VERSION |B|E|F| TYPE_T| RESRVD|         OPTIONS_LENGTH        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            ID_LENGTH          |           TYPE_LENGTH         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          DATA_LENGTH                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               /
     /                     OPTIONS + PADDING                         /
     /                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               /
     /                          ID + PADDING                         /
     /                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               /
     /                        TYPE + PADDING                         /
     /                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               /
     /                        DATA + PADDING                         /
     /                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


        Figure 3: DIME Record Layout. The use of "/" indicates a
        field length which is a multiple of 4 octets.






Nielsen, et al.                                              [Page 14]


INTERNET-DRAFT                     DIME                     June, 2002

3.2.1 Version


     An unsigned 5-bit integer that indicates the format of the DIME
     record (see section 2.2). This document defines version 1 (0x01). A
     DIME generator conforming to this specification MUST generate DIME
     messages with a VERSION field value of 0x01. A DIME parser
     conforming to this specification MUST verify that the VERSION field
     has a value of 0x01.


3.2.2 MB (Message Begin)


     The MB flag is a 1 bit field that when set indicates the start of a
     DIME message (see section 2.1.1).


3.2.3 ME (Message End)


     The ME flag is a 1 bit field that when set indicates the end of a
     DIME message (see section 2.1.1). Note, that in case of a chunked
     payload, the ME flag is set only in the terminating record chunk of
     the last chunked payload (see section 2.1.3).


3.2.4 CF (Chunk Flag)


     The CF flag is a 1 bit field indicating that this is either the
     first record chunk or a middle record chunk of a chunked payload
     (see section 2.1.3 for a description of how to encode a chunked
     payload).


3.2.5 TYPE_T


     The TYPE_T field value indicates the structure and format of the
     value of the TYPE field (see section 2.3.2 for a description of the
     TYPE field and section 4 for a description of internationalization
     issues related to the TYPE field). The TYPE_T field is a 4 bit
     field with values defined in Table 1:











Nielsen, et al.                                              [Page 15]


INTERNET-DRAFT                     DIME                     June, 2002


       TYPE_T                                        Value


       Unchanged (see section 2.1.3)                  0x00


       media-type as defined in RFC 2616 [11]         0x01


       absoluteURI as defined in RFC 2396 [10]        0x02


       Unknown                                        0x03


       None                                           0x04


       Reserved                                    0x05-0x0F


        Table 1: DIME TYPE_T field values.


     The value 0x00 (Unchanged) MUST be used in all middle record chunks
     and terminating record chunks used in chunked payloads (see section
     2.1.3). It MUST NOT be used in any other record. When used, the
     TYPE_LENGTH field value MUST be zero.


     The value 0x01 (media-type) indicates that the TYPE field contains
     a value that follows the "media-type" BNF construct defined by RFC
     2616 [11] (see section 2.3.2).


     The value 0x02 (absoluteURI) indicates that the TYPE field contains
     a value that follows the "absoluteURI" BNF construct defined by RFC
     2396 [10] (see section 2.3.2).


     The value 0x03 (Unknown) SHOULD be used to indicate that the type
     of the payload is unknown. This is similar to the
     "application/octet-stream" media type defined by MIME [7]. When
     used, the TYPE_LENGTH field value MUST be zero. Regarding
     implementation, it is RECOMMENDED that a DIME parser receiving a
     DIME record of this type provides a mechanism for storing but not
     processing the payload (see section 5).


     The value 0x04 (None) indicates that there is no type or payload
     associated with this record. When used, the value of the
     TYPE_LENGTH and the DATA_LENGTH fields MUST be zero. This TYPE_T

Nielsen, et al.                                              [Page 16]


INTERNET-DRAFT                     DIME                     June, 2002

     value can be used whenever an empty record is needed, for example
     in order to terminate a DIME message in cases where there is no
     payload defined by the user application.


     There is no default value for the TYPE_T field. Reserved TYPE_T
     field values are for future use and MUST NOT be used. A DIME parser
     that receives a DIME record with an unknown TYPE_T field value
     SHOULD treat the payload as if it had been marked with a value of
     0x03 (Unknown). Note, that in this case the TYPE_LENGTH is not
     required to be zero.


3.2.6 RESRVD


     The RESRVD field is reserved for future use and MUST be set to
     0x00. A DIME parser that receives a DIME record with a RESRVD field
     value other than 0x00 MUST discard that message as faulty.


3.2.7 OPTIONS_LENGTH


     An unsigned 16 bit integer that specifies the length in octets of
     the OPTIONS field excluding any padding used to achieve a 4 octet
     alignment of the OPTIONS field (see section 2.4).


3.2.8 ID_LENGTH


     An unsigned 16 bit integer that specifies the length in octets of
     the ID field excluding any padding used to achieve a 4 octet
     alignment of the ID field (see section 2.3.3).


3.2.9 TYPE_LENGTH


     An unsigned 16 bit integer that specifies the length in octets of
     the TYPE field excluding any padding used to achieve a 4 octet
     alignment of the TYPE field (see section 2.3.2).


3.2.10 DATA_LENGTH


     The DATA_LENGTH field is an unsigned 32 bit integer that specifies
     the length in octets of the DATA field excluding any padding used
     to achieve a 4 octet alignment of the DATA field (see section
     2.3.1).



Nielsen, et al.                                              [Page 17]


INTERNET-DRAFT                     DIME                     June, 2002

     A payload size of 0 octets is allowed. Payloads larger than 2^32-1
     octets can be accommodated by using chunked payloads (see section
     2.1.3).


3.2.11 OPTIONS


     The OPTIONS field contains 0 or more option elements where each
     element follows the layout in Figure 4 (see section 2.4 for a
     description of option elements):


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            ELEMENT_T          |         ELEMENT_LENGTH        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               /
     /                         ELEMENT_DATA                          /
     /                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


        Figure 4: DIME option element layout. The use of "/"
        indicates a field length which is a multiple of 4 octets.


     All DIME records MAY have a non-zero OPTIONS field. A DIME parser
     receiving a DIME record with an unrecognized option element type
     SHOULD ignore that element (see section 6.2 for IANA guidelines for
     registration of new option element types).


     The length of each element does not have to be a multiple of 4
     octets and there is no padding between elements. However, the size
     of the OPTIONS field MUST be a multiple of 4 octets. If the length
     of all the elements is not a multiple of 4 octets, the generator
     MUST pad the OPTIONS field value with all zero octets. Padding is
     not included in the OPTIONS_LENGTH field (see section 3.2.7).


     A DIME generator MUST NOT pad the OPTIONS field with more than 3
     octets. A DIME parser MUST ignore the padding octets.


3.2.12 ID


     The value of the ID field is an identifier in the form of a URI
     [10] (see section 2.3.3 and 3.3). The required uniqueness of the
     message identifier is guaranteed by the generator. The URI can be
     either relative or absolute; DIME does not define a base URI which


Nielsen, et al.                                              [Page 18]


INTERNET-DRAFT                     DIME                     June, 2002

     means that user applications using relative URIs MUST provide an
     actual or a virtual base URI (see [10]).


     With the exception of subsequent record chunks (see section 2.1.3),
     all records MAY have a non-zero ID field.


     The length of the ID field MUST be a multiple of 4 octets. If the
     length of the payload id value is not a multiple of 4 octets, the
     generator MUST pad the value with all zero octets. Padding is not
     included in the ID_LENGTH field (see section 3.2.8).


     A DIME generator MUST NOT pad the ID field with more than 3 octets.
     A DIME parser MUST ignore the padding octets.


3.2.13 TYPE


     The value of the TYPE field is an identifier describing the type of
     the payload (see section 2.3.2). The value of the TYPE field MUST
     follow the structure implied by the value of the TYPE_T field (see
     section 3.2.5).


     The length of the TYPE field MUST be a multiple of 4 octets. If the
     length of the payload type value is not a multiple of 4 octets, the
     generator MUST pad the value with all zero octets. Padding is not
     included in the TYPE_LENGTH field (see section 3.2.9).


     A DIME generator MUST NOT pad the TYPE field with more than 3
     octets. A DIME parser MUST ignore the padding octets.


     A DIME parser receiving a DIME record with a known TYPE_T field
     value but an unknown TYPE field value SHOULD interpret the type
     identifier of that record as if the TYPE_T field value was 0x03
     (Unknown).


     It is STRONGLY RECOMMENDED that the identifier be globally unique
     and maintained with stable and well-defined semantics over time.


3.2.14 DATA


     The DATA field carries the payload intended for the DIME user
     application. Any internal structure of the data carried within the
     DATA field is opaque to DIME.


Nielsen, et al.                                              [Page 19]


INTERNET-DRAFT                     DIME                     June, 2002

     The length of the DATA field MUST be a multiple of 4 octets. If the
     length of the payload is not a multiple of 4 octets, the generator
     MUST pad the value with all zero octets. Padding is not included in
     the DATA_LENGTH field (see section 3.2.10).


     A DIME generator MUST NOT pad the DATA field with more than 3
     octets. A DIME parser MUST ignore the padding octets.


3.3  Use of URIs in DIME


     DIME uses URIs [10] for some identifiers. To DIME, a URI is simply
     a formatted string that identifiesûvia name, location, or any other
     characteristicûa resource on the Web.


     The use of IP addresses in URIs SHOULD be avoided whenever possible
     (see RFC 1900 [5]). However, when used, the literal format for Ipv6
     addresses in URIs as described by RFC 2732 [15] SHOULD be
     supported.


     DIME does not define any equivalence rules for URIs in general as
     these are defined by the individual URI schemes and by RFC 2396
     [10]. However, because of inconsistencies with respect to some URI
     equivalence rules in many current URI parsers, it is STRONGLY
     RECOMMENDED that generators of DIME messages only rely on the most
     rudimentary equivalence rules defined by RFC 2396.


     The size of URIs used as values in the ID field and the TYPE field
     is limited by the maximum size of these fields which is 2^16-1
     octets. DIME parsers and generators MUST be able to deal with URIs
     of this size.


4  Internationalization Considerations


     Identifiers used in DIME such as URIs and MIME media type
     constructs provide different levels of support for
     internationalization. It is STRONGLY RECOMMENDED that the
     definitions and guidelines for internationalization support of
     these values be followed when used in DIME. In particular, the
     following fields require special attention:


     o    For the ID field, implementers are referred to RFC 2718 [14]
          for internationalization considerations of URIs.




Nielsen, et al.                                              [Page 20]


INTERNET-DRAFT                     DIME                     June, 2002

     o    For a TYPE_T value of 0x01 (media types), implementers are
          referred to RFC 2046 [7] for internationalization
          considerations of MIME media types.


     o    For a TYPE_T value of 0x02 (absolute URI), implementers are
          referred to RFC 2718 [14] for internationalization
          considerations of URIs.


     For ELEMENT_T values and TYPE_T values not defined by this
     specification, implementers are referred to the documentation of
     such features for specific internationalization considerations.


5  Security Considerations


     Implementers should pay special attention to the security
     implications of any record types that can cause the remote
     execution of any actions in the recipient's environment. Before
     accepting records of any type, an application should be aware of
     the particular security implications associated with that type.


     Security considerations for media types in general are discussed in
     RFC 2048 [8] and in the context of the "application/postscript" and
     the "message/external-body" media type in RFC 2046 [7].


          Note: This specification does not presently define any
          mechanisms for providing security for DIME messages and header
          information.  Future revisions of this specification will
          address this open issue.


6  IANA Considerations


     This draft describes a new media type, "application/dime" for which
     section 6.1 contains a registration application following the
     guidelines in RFC 2048 [8].


     Section 6.2 contains guidelines for definition and registration of
     additional DIME options (see section 2.4).


6.1  Media Type Registration: application/dime


     MIME media type name: application



Nielsen, et al.                                              [Page 21]


INTERNET-DRAFT                     DIME                     June, 2002

     MIME subtype name: dime


     Required parameters: none


     Optional parameters: none


     Encoding considerations:


          This media type MAY be encoded as appropriate for the charset
          and the capabilities of the underlying MIME transport. For 7-
          bit transports, data using 8-bit or higher MUST be encoded in
          quoted-printable or base64 content-transfer-encodings. For 8-
          bit clean transport (e.g., 8BITMIME [2] ESMTP [4] or NNTP
          [1]), 8-bit data such as UTF-8 does not need to be encoded.
          Over HTTP [11], no content-transfer-encoding is necessary
          regardless of the encoding.


     Security considerations: See section 5


     Interoperability considerations: n/a


     Published Specification: this specification


     Applications which use this media type:


          Applications that choose to use DIME as the packaging
          mechanism for encapsulating one or more application-defined
          payloads of arbitrary type and size into a single message
          construct.


     Additional information: none


     Magic number(s): none


     File extension(s):


          .dim
          .dime




Nielsen, et al.                                              [Page 22]


INTERNET-DRAFT                     DIME                     June, 2002

     Macintosh File Type Code(s):


          DIME


     Person and email address for further information: see section 10


     Intended usage:


          COMMON


     Author/Change controller:


          The DIME specification is an individual Internet Draft
          submission. It is not the product of an IETF Working Group.
          The IETF has change control over the DIME specification.


6.2  Guidelines for Registration of DIME Option Element Types


     The registration process of DIME option element types follows the
     guidelines for "IETF Consensus" as defined in RFC 2434 [11] where
     new ELEMENT_T values are assigned through the IETF consensus
     process. Specifically, new assignments are made via RFCs approved
     by the IESG. Typically, the IESG will seek input on prospective
     assignments from appropriate persons (e.g., a relevant Working
     Group if one exists).


     The following process is designed to ensure that new DIME option
     elements are reviewed for technical correctness and appropriateness
     and that their description is complete and published before an
     ELEMENT_T value is assigned by IANA.


     1.   The author(s) document(s) the option element, leaving the
          ELEMENT_T value as "To Be Determined" (TBD). It is important
          that security and internationalization concerns for the option
          element be addressed. It is STRONGLY RECOMMENED that the
          documentation be published as an Internet Draft.


     2.   The author(s) submit(s) the Internet Draft for review by the
          IESG and any relevant working groups (IETF or otherwise).


     3.   The specification of the new option element is reviewed by the
          IESG, the IETF, and other relevant groups identified in 2). If

Nielsen, et al.                                              [Page 23]


INTERNET-DRAFT                     DIME                     June, 2002

          the option element is accepted for inclusion in the DIME
          specification, the specification of the option is published as
          either a standards-track or a non-standards-track RFC.


     4.   At the time of publication as an RFC, IANA assigns a DIME
          ELEMENT_T value for the new option element. The option is not
          to be used in published implementations before IANA has
          assigned an ELEMENT_T value.


7  Intellectual Property


     The following notice is copied from RFC 2026 [6], Section 10.4, and
     describes the position of the IETF concerning intellectual property
     claims made against this document.


     The IETF takes no position regarding the validity or scope of any
     intellectual property or other rights that might be claimed to
     pertain to the implementation or use other technology described in
     this document or the extent to which any license under such rights
     might or might not be available; neither does it represent that it
     has made any effort to identify any such rights.  Information on
     the procedures of the IETF with respect to rights in standards-
     track and standards-related documentation can be found in BCP-11.
     Copies of claims of rights made available for publication 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 Secretariat.


     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 practice
     this standard. Please address the information to the IETF Executive
     Director.


8  Acknowledgements


     Special thanks go to Paul H. Gleichauf and Krishna Sankar of Cisco
     for their input on this specification.


9  References

     [1]   B. Kantor, P. Lapsley, "Network News Transfer Protocol", RFC
           977, U.C. San Diego, U.C. Berkeley, February 1986



Nielsen, et al.                                              [Page 24]


INTERNET-DRAFT                     DIME                     June, 2002

     [2]   J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker,
           "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652,
           MCI, Innosoft, Dover Beach Consulting, Inc., Network
           Management Associates, Inc., Silicon Graphics, Inc., July
           1994.
     [3]   Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
           1700, October 1994.
     [4]   J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "
           SMTP Service Extensions", RFC 1869, MCI, Innosoft
           International, Inc., Dover Beach Consulting, Inc., Network
           Management Associates, Inc., Brandenburg Consulting, Inc.,
           November 1995.
     [5]   B. Carpenter, Y. Rekhter, "Renumbering Needs Work", RFC
           1900, IAB, February 1996
     [6]   S. Bradner, "The Internet Standards Process û Revision 3",
           RFC 2026, Harvard University, October 1996
     [7]   N. Freed, N. Borenstein, "Multipurpose Internet Mail
           Extensions (MIME) Part Two: Media Types" RFC 2046, Innosoft
           First Virtual, November 1996
     [8]   N. Freed, J. Klensin, J. Postel, "Multipurpose Internet Mail
           Extensions (MIME) Part Four: Registration Procedures", RFC
           2048, Innosoft, MCI, ISI, November 1996
     [9]   S. Bradner, "Key words for use in RFCs to Indicate
           Requirement Levels", RFC 2119, Harvard University, March
           1997
     [10]  T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource
           Identifiers (URI): Generic Syntax", RFC 2396, MIT/LCS, U.C.
           Irvine, Xerox Corporation, August 1998.
     [11]  T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
           Considerations Section in RFCs", BCP 26, RFC 2434, October
           1998.
     [12]  R. Fielding, J. Gettys, J. C. Mogul, H. F. Nielsen, T.
           Berners-Lee, "Hypertext Transfer Protocol û HTTP/1.1", RFC
           2616, U.C. Irvine, DEC W3C/MIT, DEC, W3C/MIT, W3C/MIT,
           January 1997
     [13]  R. Petke, I. King, "Registration Procedures for URL Scheme
           Names", BCP: 35, RFC 2717, UUNET Technologies, Microsoft
           Corporation, November 1999
     [14]  L. Masinter, H. Alvestrand, D. Zigmond, R. Petke,
           "Guidelines for new URL Schemes", RFC 2718, Xerox
           Corporation, Maxware, Pirsenteret, WebTV Networks, Inc.,
           UUNET Technologies, November 1999
     [15]  R. Hinden, B. Carpenter, L. Masinter, "Format for Literal
           Ipv6 Addresses in URL's", RFC 2732, Nokia, IBM, AT&T,
           December 1999
     [16]  M. Murata, S. St.Laurent, D. Kohn, "XML Media Types" RFC
           3023, IBM Tokyo Research Laboratory, simonstl.com, Skymoon
           Ventures, January 2001
     [17]  List of Uniform Resource Identifier (URI) schemes registered
           by IANA is available at
           "http://www.iana.org/assignments/uri-schemes"




Nielsen, et al.                                              [Page 25]


INTERNET-DRAFT                     DIME                     June, 2002

10 Authors' Addresses


     Henrik Frystyk Nielsen
     Microsoft
     One Microsoft Way, Redmond, WA 90852
     Email: henrikn@microsoft.com


     Henry Sanders
     Microsoft
     One Microsoft Way, Redmond, WA 90852
     Email: henrysa@microsoft.com


     Russell Butek
     IBM
     11501 Burnet Road, Austin, TX 78758
     Email: butek@us.ibm.com


     Simon Nash
     IBM
     Hursley Park, Winchester, UK
     Email: nash@hursley.ibm.com






























Nielsen, et al.                                              [Page 26]