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 identifiesvia name, location, or any other 
     characteristica 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]