

INTERNET-DRAFT                             Henrik Frystyk Nielsen, 
draft-nielsen-dime-01                      Henry Sanders,  
                                           Erik Christensen, 
                                           Christian Huitema, 
                                           Microsoft, 
Expires August 2002                        February 01, 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. Discussions are 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 
     optional payload identifier is a URI enabling cross-referencing 
 
Nielsen, et al.                                               [Page 1] 
INTERNET-DRAFT                     DIME                  October, 2001 
 
     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...................................3 
     1.2   Design Goals.............................................4 
     1.3   DIME Terminology.........................................5 
     1.4   Intended Usage...........................................6 
     2  The DIME Mechanisms.........................................7 
     2.1   DIME Encapsulation Constructs............................7 
     2.1.1   Message................................................7 
     2.1.2   Record.................................................8 
     2.1.3   Record Chunks..........................................8 
     2.2   DIME Payload Description.................................9 
     2.2.1   Payload Length.........................................9 
     2.2.2   Payload Type...........................................9 
     2.2.3   Payload Identification................................11 
     3  The DIME Specifications....................................11 
     3.1   Data Transmission Order.................................11 
     3.2   Record Layout...........................................12 
     3.2.1   MB (Message Begin)....................................12 
     3.2.2   ME (Message End)......................................12 
     3.2.3   CF (Chunk Flag).......................................13 
     3.2.4   ID_LENGTH.............................................13 
     3.2.5   TNF (Type Name Format)................................13 
     3.2.6   TYPE_LENGTH...........................................14 
     3.2.7   DATA_LENGTH...........................................14 
     3.2.8   ID....................................................15 
     3.2.9   TYPE..................................................15 
     3.2.10  DATA..................................................16 
     3.3   Use of URIs in DIME.....................................16 
     4  Internationalization Considerations........................17 
     5  Security Considerations....................................17 
     6  IANA Considerations........................................17 
     6.1   Registration: application/dime..........................17 
     7  Intellectual Property......................................19 
     8  Acknowledgements...........................................19 
     9  References.................................................19 
     10 Authors' Addresses.........................................20 
 








 
Nielsen, et al.                                               [Page 2] 
INTERNET-DRAFT                     DIME                  October, 2001 
 

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.2.1). By providing the payload length 
          within the first 8 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.2.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.2.3). The use of an 
          identifier enables payloads that support URI linking 
          technologies to cross-reference other payloads. 


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





 
Nielsen, et al.                                               [Page 3] 
INTERNET-DRAFT                     DIME                  October, 2001 
 
1.2  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. 


     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. 

 
Nielsen, et al.                                               [Page 4] 
INTERNET-DRAFT                     DIME                  October, 2001 
 
1.3  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 payload  


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


     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.2.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.2.2). 
 
Nielsen, et al.                                               [Page 5] 
INTERNET-DRAFT                     DIME                  October, 2001 
 
     DIME payload identifier  


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


     DIME user application  


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


     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.4  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 considerations 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). 

 
Nielsen, et al.                                               [Page 6] 
INTERNET-DRAFT                     DIME                  October, 2001 
 
     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. 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. 


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.2). 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) 

 
Nielsen, et al.                                               [Page 7] 
INTERNET-DRAFT                     DIME                  October, 2001 
 
        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.  


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.2).  


2.1.3 Record Chunks 


     A record chunk carries 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 as a DIME record 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.3). 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.2.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 TNF (Type Name Format) 
          field value MUST be 0x00 (see section 3.2.4). The DATA_LENGTH 
 
Nielsen, et al.                                               [Page 8] 
INTERNET-DRAFT                     DIME                  October, 2001 
 
          field indicates the size of the data carried in the DATA field 
          (see section 2.2.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 TNF (Type Name Format) field value MUST be 0x00 
          (see section 3.2.4). The DATA_LENGTH field indicates the size 
          of the data carried in DATA field (see section 2.2.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 Payload Description 


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


2.2.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. Note that zero is a 
     valid length. 


2.2.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 
 
Nielsen, et al.                                               [Page 9] 
INTERNET-DRAFT                     DIME                  October, 2001 
 
     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 format of the TYPE field value is indicated using the TNF (Type 
     Name Format) 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 [12]. It is 
     recommended that only well-known URI schemes registered by IANA be 
     used (see [16] 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 


          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" 
 
Nielsen, et al.                                              [Page 10] 
INTERNET-DRAFT                     DIME                  October, 2001 
 
     indicates that the payload is an XML document as defined by RFC 
     3023 [15].  


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


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. 


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


        Figure 2: DIME octet ordering 


     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. 



 
Nielsen, et al.                                              [Page 11] 
INTERNET-DRAFT                     DIME                  October, 2001 
 
     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. 


                                     1  1  1  1  1  1 
       0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5 
     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
     |MB|ME|CF|              ID_LENGTH               | 
     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
     |   TNF  |             TYPE_LENGTH              | 
     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
     |                  DATA_LENGTH                  | 
     |                                               | 
     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
     |                  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. 


3.2.1 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.2 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 
     that chunked payload (see section 2.1.3). 
 
Nielsen, et al.                                              [Page 12] 
INTERNET-DRAFT                     DIME                  October, 2001 
 
3.2.3 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.4 ID_LENGTH 


     An unsigned 13 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.2.3). 


3.2.5 TNF (Type Name Format) 


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


       Type Name Format                              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-0x07 


        Table 1: DIME TNF field values. 


     The value 0x00 (Unchanged) MUST be used in all middle record chunks 
     and terminating record chunks used in chunked payloads (see section 
 
Nielsen, et al.                                              [Page 13] 
INTERNET-DRAFT                     DIME                  October, 2001 
 
     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.2.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.2.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 TNF 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 TNF field. Reserved TNF field 
     values are for future use and MUST NOT be used. A DIME parser that 
     receives a DIME record with an unknown TNF field value SHOULD treat 
     it as 0x03 (Unknown). 


3.2.6 TYPE_LENGTH 


     An unsigned 13 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.2.2). 


3.2.7 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.2.1). 


 
Nielsen, et al.                                              [Page 14] 
INTERNET-DRAFT                     DIME                  October, 2001 
 
     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.8 ID 


     The value of the ID field is an identifier in the form of a URI 
     [10] (see section 2.2.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 
     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.4). 


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


3.2.9 TYPE 


     The value of the TYPE field is an identifier describing the type of 
     the payload (see section 2.2.2). The value of the TYPE field MUST 
     follow the structure implied by the value of the TNF 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.6). 


     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 TNF field value 
     but an unknown TYPE field value SHOULD interpret the type 
     identifier of that record as if the TNF field value was 0x03 
     (Unknown). 

 
Nielsen, et al.                                              [Page 15] 
INTERNET-DRAFT                     DIME                  October, 2001 
 
     It is STRONGLY RECOMMENDED that the identifier be globally unique 
     and maintained with stable and well-defined semantics over time. 


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


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


     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 [14] 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^13-1 
     octets. DIME parsers and generators MUST be able to deal with URIs 
     of this size. 






 
Nielsen, et al.                                              [Page 16] 
INTERNET-DRAFT                     DIME                  October, 2001 
 
4  Internationalization Considerations 


     Identifiers used in DIME such as URIs and MIME media type 
     constructs may provide different levels of support for 
     internationalization. Implementers are referred to RFC 2718 [13] 
     for internationalization consideration of URIs and RFC 2046 [7] for 
     internationalization considerations of MIME media types. 


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


6  IANA Considerations 


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


6.1  Registration: application/dime 


     MIME media type name: application 


     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 
 
Nielsen, et al.                                              [Page 17] 
INTERNET-DRAFT                     DIME                  October, 2001 
 
          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 


     Macintosh File Type Code(s): 


          DIME 


     Person and email address for further information: see section 10 


     Intended usage: 


          COMMON 



 
Nielsen, et al.                                              [Page 18] 
INTERNET-DRAFT                     DIME                  October, 2001 
 
     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. 


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 
     [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. 
 
Nielsen, et al.                                              [Page 19] 
INTERNET-DRAFT                     DIME                  October, 2001 
 
     [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]  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 
     [12]  R. Petke, I. King, "Registration Procedures for URL Scheme 
           Names", BCP: 35, RFC 2717, UUNET Technologies, Microsoft 
           Corporation, November 1999 
     [13]  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 
     [14]  R. Hinden, B. Carpenter, L. Masinter, "Format for Literal 
           IPv6 Addresses in URL's", RFC 2732, Nokia, IBM, AT&T, 
           December 1999 
     [15]  M. Murata, S. St.Laurent, D. Kohn, "XML Media Types" RFC 
           3023, IBM Tokyo Research Laboratory, simonstl.com, Skymoon 
           Ventures, January 2001 
     [16]  List of Uniform Resource Identifier (URI) schemes registered 
           by IANA is available at 
           "http://www.iana.org/assignments/uri-schemes" 

10 Authors' Addresses 


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



 
Nielsen, et al.                                              [Page 20] 
INTERNET-DRAFT                     DIME                  October, 2001 
 
     Henry Sanders 
     Microsoft 
     One Microsoft Way, Redmond, WA 90852 
     Email: henrysa@microsoft.com 


     Erik Christensen 
     Microsoft 
     One Microsoft Way, Redmond, WA 90852 
     Email: erikc@microsoft.com 


     Christian Huitema 
     Microsoft 
     One Microsoft Way, Redmond, WA 90852 
     Email: huitema@microsoft.com 


 



































 
Nielsen, et al.                                              [Page 21] 