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]