idnits 2.17.1 draft-nielsen-dime-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2001) is 8195 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 706, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 710, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 712, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 720, but no explicit reference was found in the text ** Obsolete normative reference: RFC 821 (ref. '1') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 1700 (ref. '2') (Obsoleted by RFC 3232) ** Downref: Normative reference to an Informational RFC: RFC 1900 (ref. '3') ** Obsolete normative reference: RFC 2048 (ref. '6') (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 2396 (ref. '8') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2616 (ref. '9') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2717 (ref. '10') (Obsoleted by RFC 4395) ** Obsolete normative reference: RFC 2718 (ref. '11') (Obsoleted by RFC 4395) ** Obsolete normative reference: RFC 2732 (ref. '12') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 3023 (ref. '13') (Obsoleted by RFC 7303) -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' Summary: 15 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Henrik Frystyk Nielsen 3 draft-nielsen-dime-00 Henry Sanders 4 Erik Christensen 5 Microsoft 6 Expires May 2002 November 2001 8 Direct Internet Message Encapsulation (DIME) 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 "http://www.ietf.org/ietf/1id-abstracts.txt" 29 The list of Internet-Draft Shadow Directories can be accessed at 30 "http://www.ietf.org/shadow.html". 32 Please send comments to the "dime@discuss.develop.com" mailing 33 list. Discussions are archived at 34 "http://discuss.develop.com/dime.html". 36 Abstract 38 Direct Internet Message Encapsulation (DIME) is a lightweight, 39 binary message format that can be used to encapsulate one or more 40 application-defined payloads of arbitrary type and size into a 41 single message construct. Each payload is described by a type, a 42 length, and an optional identifier. Both URIs and MIME media type 43 constructs are supported as type identifiers. The payload length is 44 an integer indicating the number of octets of the payload. The 45 optional payload identifier is a URI enabling cross-referencing 46 between payloads. DIME payloads may include nested DIME messages or 47 chains of linked chunks of unknown length at the time the data is 48 generated. DIME is strictly a message format, provides no concept 49 of a connection or of a logical circuit, and does not address head- 50 of-line problems. 52 Table of Contents 54 1 Introduction................................................3 55 1.1 Notational Conventions...................................3 56 1.2 Design Goals.............................................4 57 1.3 DIME Terminology.........................................5 58 1.4 Intended Usage...........................................6 60 2 The DIME Mechanisms.........................................7 61 2.1 DIME Encapsulation Constructs............................7 62 2.1.1 Message................................................7 63 2.1.2 Record.................................................8 64 2.1.3 Chunked Records........................................8 65 2.2 DIME Payload Description.................................9 66 2.2.1 Payload Length.........................................9 67 2.2.2 Payload Type...........................................9 68 2.2.3 Payload Identification................................10 70 3 The DIME Specifications....................................11 71 3.1 Data Transmission Order.................................11 72 3.2 Record Layout...........................................11 73 3.2.1 MB (Message Begin)....................................12 74 3.2.2 ME (Message End)......................................12 75 3.2.3 CF (Chunked Flag).....................................12 76 3.2.4 ID_LENGTH.............................................12 77 3.2.5 TNF (Type Name Format)................................13 78 3.2.6 TYPE_LENGTH...........................................13 79 3.2.7 DATA_LENGTH...........................................13 80 3.2.8 ID....................................................14 81 3.2.9 TYPE..................................................14 82 3.2.10 DATA..................................................15 83 3.3 Use of URIs in DIME.....................................15 85 4 Internationalization Considerations........................15 87 5 Security Considerations....................................16 89 6 IANA Considerations........................................16 91 7 Intellectual Property......................................16 93 8 Acknowledgements...........................................17 95 9 References.................................................17 97 10 Authors' Addresses.........................................18 98 1 Introduction 100 Direct Internet Message Encapsulation (DIME) is a lightweight, 101 binary message format designed to encapsulate one or more 102 application-defined payloads into a single message construct. A 103 DIME message contains one or more DIME records each carrying a 104 payload of arbitrary type and up to 2^32-1 octets in size. Records 105 can be chained together to support larger payloads. A DIME record 106 carries three parameters for describing its payload: the payload 107 length, the payload type, and an optional payload identifier. The 108 purpose of these parameters is as follows: 110 The payload length 112 The payload length indicates the number of octets in the 113 payload (see section 2.2.1). By providing the payload length 114 within the first 8 octets of a record, efficient record 115 boundary detection is possible. 117 The payload type 119 The DIME payload type identifier indicates the type of the 120 payload. DIME supports both URIs [8] as well as MIME media 121 type constructs [5] as type identifiers (see section 2.2.2). 122 Based on the indicated type of a payload, it is possible to 123 dispatch the payload to the appropriate user application. 125 The payload identifier 127 A payload can optionally be given an identifier in the form of 128 an absolute or relative URI (see section 2.2.3). This enables 129 payloads that support URI linking technologies to cross- 130 reference other payloads. 132 1.1 Notational Conventions 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 136 this document are to be interpreted as described in RFC 2119 [5]. 138 1.2 Design Goals 140 Because of the large number of existing message encapsulation 141 formats, record marking protocols and multiplexing protocols, we 142 would like to be explicit about the design goals of DIME and, in 143 particular, about what is outside the scope of DIME. 145 The design goal of DIME is to provide an efficient and simple 146 message format that can accommodate the following: 148 1. Encapsulating arbitrary documents and entities, including 149 encrypted data, XML documents, XML fragments, image data like 150 GIF and JPEG files, etc. 152 2. Encapsulating documents and entities initially of unknown 153 size. This capability can be used to encapsulate dynamically 154 generated content or very large entities as a series of 155 chunks. 157 3. Aggregating multiple documents and entities that are logically 158 associated in some manner into a single message. For example, 159 DIME can be used to encapsulate a SOAP message and a set of 160 attachments referenced from that SOAP message. 162 In order to achieve efficiency and simplicity, the mechanisms 163 provided by this specification have been deliberately limited to 164 serve these purposes. DIME has explicitly not been designed as a 165 general message description or document format such as MIME or XML. 166 Instead, DIME-based applications can take advantage of such formats 167 by encapsulating them in DIME messages. 169 The following list identifies what is outside the scope of DIME: 171 1. DIME must not make any assumptions about the types of payloads 172 that are carried within DIME messages or about the message 173 exchange patterns of such messages. 175 2. DIME must not in any way introduce the notion of a connection 176 or of a logical circuit (virtual or otherwise). 178 3. DIME must not attempt to deal with head-of-line blocking 179 problems that might occur when using stream-oriented protocols 180 like TCP. 182 1.3 DIME Terminology 184 DIME message 186 The basic message construct defined by this specification. A 187 DIME message contains one or more DIME records (see section 188 2.1.1). 190 DIME record 192 A DIME record contains a payload described by a type, a 193 length, and an optional identifier (see section 2.1.2). 195 DIME chunked record 197 A DIME record that contains parts of dynamically generated 198 content or very large entities that have been partitioned into 199 multiple DIME records within the same DIME message (see 200 section 2.1.3). 202 DIME payload 204 The data carried within a record defined by a user 205 application. 207 DIME payload length 209 The size of the payload indicated in number of octets (see 210 section 2.2.1). 212 DIME payload type 214 An identifier that indicates the type of the payload. This 215 specification supports both URIs [8] as well as MIME media 216 type constructs [5] as type identifiers (see section 2.2.2). 218 DIME payload identifier 220 A URI that can optionally be used to identify a payload (see 221 section 2.2.3) 222 DIME user application 224 The logical, higher-layer application that uses DIME for 225 encapsulating messages. 227 DIME generator 229 A software entity or module that encapsulates user 230 application-defined payloads within DIME messages. 232 DIME parser 234 A software entity or module that parses DIME messages and 235 hands off the payloads to a DIME user application. 237 1.4 Intended Usage 239 The intended usage of DIME is as follows: A user application wants 240 to encapsulate one or more related documents into a single DIME 241 message. For example, this can be a SOAP message along with a set 242 of attachments. The DIME generator encapsulates each document 243 within a DIME record, indicating the type and length of the payload 244 along with an optional identifier. These records are then put 245 together to form a single DIME message. The DIME parser 246 deconstructs the DIME message and hands the payloads to a 247 (potentially different) user application. 249 DIME can be used in combination with most protocols that support 250 the exchange of binary data as long as the DIME message can be 251 exchanged in its entirety. A DIME message can be carried as a MIME 252 entity using the media type "application/dime" (see section 6 for 253 IANA media type registration considerations of "application/dime"). 255 DIME records can encapsulate any message type. It is possible to 256 carry MIME messages in DIME records by using a media type such as 257 "message/rfc822". A DIME message can be encapsulated in a DIME 258 record by using the media type "application/dime" (see section 6). 260 It is important to note that although MIME entities are supported, 261 there are no assumptions in DIME that a record payload is MIME; 262 DIME makes no assumption concerning the type of the payloads 263 carried in a DIME message. 265 DIME provides no support for error handling. It is up to the DIME 266 parser to determine the implications of receiving a malformed DIME 267 message. It is the responsibility of the user applications involved 268 to provide any additional functionality such as QoS that they may 269 need as part of the overall system in which they participate. 271 2 The DIME Mechanisms 273 This section describes the mechanisms used in DIME. The specific 274 syntax for these mechanisms is defined in section 3. 276 2.1 DIME Encapsulation Constructs 278 2.1.1 Message 280 A DIME message is composed of one or more DIME records. The first 281 record in a message is marked with the MB (Message Begin) flag set 282 and the last record in the message is marked with the ME (Message 283 End) flag set (see section 3.2.1 and 3.2.2). The minimum message 284 length is one record which is achieved by setting both the MB and 285 the ME flag in the same record. There is no maximum number of DIME 286 records that can be carried within a single DIME message. 288 DIME messages MUST NOT overlap. That is, the MB and the ME flags 289 MUST NOT be used to nest DIME messages. DIME messages can be nested 290 by carrying a full DIME message within a DIME record with the type 291 "application/dime" (see section 6). 293 <--------------------- DIME message ----------------------> 294 +---------+ +---------+ +---------+ +---------+ 295 | R1 MB=1 | ... | Rr | ... | Rs | ... | Rt ME=1 | 296 +---------+ +---------+ +---------+ +---------+ 298 Figure 1: Example of a DIME message with a set of records. 299 The message head is to the left and the tail to the right 300 with the logical record indexes t > s > r > 1. The MB 301 (Message Begin) flag is set in the first record (index 1) 302 and the ME (Message End) flag is set in the last record 303 (index t). 305 Note that actual DIME records do not carry an index number; the 306 ordering is implicitly given by the order in which the records are 307 serialized. 309 2.1.2 Record 311 A record is the unit for carrying a payload within a DIME message. 312 Each payload is described by its own set of parameters (see section 313 2.2). 315 2.1.3 Chunked Records 317 Chunked records can be used to partition dynamically generated 318 content or very large entities into multiple subsequent DIME 319 records serialized within the same DIME message. 321 Chunking is not a mechanism for introducing multiplexing into DIME. 322 It is a mechanism to limit the need for outbound buffering on the 323 generating side. This is similar to the message chunking mechanism 324 defined in HTTP/1.1 [9]. 326 A DIME message can contain zero or more chunked record series. A 327 chunked record series contains an initial record followed by zero 328 or more middle records followed by a terminating record. The 329 encoding rules are as follows: 331 1. The initial record is indicated by having the CF (Chunked 332 Flag) flag set (see section 3.2.3). The type of the payload 333 MUST be indicated in the TYPE field regardless of whether the 334 DATA_LENGTH field value is zero or not. The DATA_LENGTH field 335 indicates the size of THIS record's DATA field (see section 336 2.2.1). The ID field MAY be used to carry an identifier of the 337 payload. 339 2. Each middle record is marked with the CF flag set indicating 340 that this record contains the next chunk of data of the same 341 type and (if provided) with the same identifier (see section 342 3.2.3). The value of the TYPE_LENGTH and the ID_LENGTH fields 343 MUST be zero and the TNF (Type Name Format) field MUST be set 344 to 0x00 (see section 3.2.4). The DATA_LENGTH field indicates 345 the size of THIS record's DATA field (see section 2.2.1). 347 3. The terminating record in a chunked record series is indicated 348 by having the CF flag cleared. Again, the value of the 349 TYPE_LENGTH and the ID_LENGTH fields MUST be 0 and the TNF 350 (Type Name Format) field MUST be set to 0x00 (see section 351 3.2.4). The DATA_LENGTH field indicates the size of THIS 352 record's DATA field (see section 2.2.1). 354 A chunked record series MUST be entirely encapsulated within a 355 single DIME message. That is, a chunked record series MUST NOT span 356 multiple DIME messages. 358 2.2 DIME Payload Description 360 Each record contains information about the payload carried within 361 itself. This section introduces the mechanisms by which these 362 payloads are described. 364 2.2.1 Payload Length 366 Regardless of the relationship of a record to other records, the 367 payload length always indicates the length of the payload 368 encapsulated in THIS record. The length of the payload is indicated 369 in number of octets in the DATA_LENGTH field. 371 2.2.2 Payload Type 373 The payload type of a record indicates the kind of data being 374 carried in the payload of that record. This may be used to guide 375 the processing of the payload at the discretion of the user 376 application. The type of the first record, by convention, provides 377 the processing context not only for the first record but for the 378 whole DIME message. Additional context for processing the message 379 may be provided by the transport service port (TCP, UDP, etc) at 380 which the message was received and by other communication 381 parameters. 383 It is important to emphasize that DIME mandates no specific 384 processing model for DIME messages. The usage of the payload types 385 is entirely at the discretion of the user application. The comments 386 regarding usage above should be taken as guidelines for building 387 processing conventions, including mappings of higher level 388 application semantics onto DIME. 390 The format of the TYPE field value is indicated using the TNF (Type 391 Name Format) field (see section 3.2.5). This specification supports 392 TYPE field values in the form of absolute URIs and MIME media type 393 constructs. The former allows for decentralized control of the 394 value space and the latter allows DIME to take advantage of the 395 already very large and successful media type value space maintained 396 by IANA [2]. 398 The media type registration process is outlined in RFC 2048 [6]. 399 Use of non-registered media types is discouraged. The URI scheme 400 registration process is described in RFC 2717 [10]. It is 401 recommended that only well-known URI schemes registered by IANA be 402 used (see [14] for a current list). 404 URIs can be used for message types that are defined by URIs. 405 Records that carry a payload with an XML-based message type MAY use 406 the XML namespace identifier of the root element as the TYPE field 407 value. A SOAP/1.1 message, for example, may be represented by the 408 URI 410 http://schemas.xmlsoap.org/soap/envelope/ 412 Records that carry a payload with an existing, registered media 413 type SHOULD carry a TYPE field value of that media type. Note that 414 the TYPE field indicates the type of the payload; it does NOT refer 415 to a MIME message that contains an entity of the given type. For 416 example, the media type 418 image/jpeg 420 indicates that the payload is a JPEG image. Similarly, the media 421 type 423 message/http 425 indicates that the payload is an HTTP message as defined by RFC 426 2616 [9]. A value of 428 application/xml; charset="utf-16" 430 indicates that the payload is an XML document as defined by RFC 431 3023 [13]. 433 2.2.3 Payload Identification 435 The optional payload identifier allows user applications to 436 identify a payload within a DIME record. By providing a payload 437 identifier, it becomes possible for other payloads supporting URI- 438 based linking technologies to refer to that payload. DIME does not 439 mandate any particular linking mechanism but leaves this to the 440 user application to define this in the language that it prefers. 442 It is important that payload identifiers are maintained so that 443 references to those payloads are not broken. If records are 444 repackaged, for example by an intermediate application, then that 445 application MUST ensure that the payload identifiers are preserved. 447 3 The DIME Specifications 449 3.1 Data Transmission Order 451 The order of transmission of the DIME record described in this 452 document is resolved to the octet level. For diagrams showing a 453 group of octets, the order of transmission of those octets is left 454 to right, top to bottom as they are read in English. For example, 455 in the diagram in Figure 2, the octets are transmitted in the order 456 they are numbered. 458 1 1 1 1 1 1 459 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 460 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 461 | Octet 1 | Octet 2 | 462 | Octet 3 | Octet 4 | 463 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 464 | Octet 5 | Octet 6 | 465 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 467 Figure 2: DIME octet ordering 469 Whenever an octet represents a numeric quantity, the leftmost bit 470 in the diagram is the high order or most significant bit. That is, 471 the bit labeled 0 is the most significant bit. 473 For each multi-octet field representing a numeric quantity defined 474 by DIME, the leftmost bit of the whole field is the most 475 significant bit. Such quantities are transmitted in a big-endian 476 manner with the most significant octet transmitted first. 478 3.2 Record Layout 480 DIME records are variable length records with a common format 481 illustrated in Figure 3. In the following sections, the individual 482 record fields are described in more detail. 484 1 1 1 1 1 1 485 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 486 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 487 |MB|ME|CF| ID_LENGTH | 488 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 489 | TNF | TYPE_LENGTH | 490 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 491 | DATA_LENGTH | 492 | | 493 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 494 | ID + PADDING / 495 / | 496 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 497 | TYPE + PADDING / 498 / | 499 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 500 | / 501 / DATA + PADDING / 502 / | 503 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 505 Figure 3: DIME Record Layout. The use of "/" indicates a 506 field length which is a multiple of 4 octets. 508 3.2.1 MB (Message Begin) 510 The MB flag is a 1 bit field that when set indicates the start of a 511 DIME message (see section 2.1.1). 513 3.2.2 ME (Message End) 515 The ME flag is a 1 bit field that when set indicates the end of a 516 DIME message (see section 2.1.1). 518 3.2.3 CF (Chunked Flag) 520 The CF flag is a 1 bit field indicating a chunked record. See 521 section 2.1.3 for a description of how to encode a chunked record 522 series. 524 3.2.4 ID_LENGTH 526 An unsigned 13 bit integer that specifies the length in octets of 527 the ID field excluding any padding used to achieve a 4 octet 528 alignment of the ID field (see section 2.2.3). 530 3.2.5 TNF (Type Name Format) 532 The TNF field value indicates the structure of the value of the 533 TYPE field (see section 2.2.2). The TNF field is a 3 bit field with 534 values defined in Table 1: 536 Type Name Format Value 538 None 0x00 540 media-type as defined in RFC 2616 [9] 0x01 542 Absolute URI as defined in RFC 2396 [8] 0x02 544 Reserved 0x03-0x07 546 Table 1: DIME TNF field values 548 Reserved TNF field values are reserved for future use and MUST NOT 549 be used. The value 0x00 MUST be used in all but the first chunk in 550 a chunked record series (see section 2.1.3). It MUST NOT be used in 551 any other record. 553 3.2.6 TYPE_LENGTH 555 An unsigned 13 bit integer that specifies the length in octets of 556 the TYPE field excluding any padding used to achieve a 4 octet 557 alignment of the TYPE field (see section 2.2.2). 559 3.2.7 DATA_LENGTH 561 The DATA_LENGTH field is an unsigned 32 bit integer that specifies 562 the length in octets of the DATA field excluding any padding used 563 to achieve a 4 octet alignment of the DATA field (see section 564 2.2.1). 566 A payload size of 0 octets is allowed. Payloads larger than 2^32-1 567 octets can be accommodated by using chunked records (see section 568 2.1.3). 570 3.2.8 ID 572 The value of the ID field is an identifier in the form of a URI [8] 573 (see section 2.2.3 and 3.3). The required uniqueness of the message 574 identifier is guaranteed by the generator. The URI can be either 575 relative or absolute; DIME does not define a base URI which means 576 that user applications using relative URIs MUST provide an actual 577 or a virtual base URI (see [8]). 579 With the exception of subsequent chunked records (see section 580 2.1.3), all records MAY have a non-zero ID field. 582 The length of the ID field MUST be a multiple of 4 octets. If the 583 length of the payload id value is not a multiple of 4 octets, the 584 generator MUST pad the value with all zero octets. Padding is not 585 included in the ID_LENGTH field (see section 3.2.4). 587 A DIME generator MUST NOT pad the ID field with more than 3 octets. 588 A DIME parser MUST ignore the padding octets. 590 3.2.9 TYPE 592 The value of the TYPE field is an identifier of structure indicated 593 by the TNF field describing the type of the payload (see section 594 2.2.2). With the exception of subsequent chunked records (see 595 section 2.1.3), all records MUST have a non-zero TYPE_LENGTH field 596 and a TYPE field value that follows the rules implied by the value 597 of the TNF field. There is no default value for the TYPE field. 599 The length of the TYPE field MUST be a multiple of 4 octets. If the 600 length of the payload type value is not a multiple of 4 octets, the 601 generator MUST pad the value with all zero octets. Padding is not 602 included in the TYPE_LENGTH field (see section 3.2.6). 604 A DIME generator MUST NOT pad the TYPE field with more than 3 605 octets. A DIME parser MUST ignore the padding octets. 607 It is STRONGLY RECOMMENDED that the identifier be globally unique 608 and maintained with stable and well-defined semantics over time. 610 3.2.10 DATA 612 The DATA field carries the payload intended for the DIME user 613 application. Any internal structure of the data carried within the 614 DATA field is opaque to DIME. 616 The length of the DATA field MUST be a multiple of 4 octets. If the 617 length of the payload is not a multiple of 4 octets, the generator 618 MUST pad the value with all zero octets. Padding is not included in 619 the DATA_LENGTH field (see section 3.2.7). 621 A DIME generator MUST NOT pad the DATA field with more than 3 622 octets. A DIME parser MUST ignore the padding octets. 624 3.3 Use of URIs in DIME 626 DIME uses URIs [8] for some identifiers. To DIME, a URI is simply a 627 formatted string that identifies�via name, location, or any other 628 characteristic�a resource on the Web. 630 The use of IP addresses in URIs SHOULD be avoided whenever possible 631 (see RFC 1900 [2]). However, when used, the literal format for IPv6 632 addresses in URIs as described by RFC 2732 [12] SHOULD be 633 supported. 635 DIME does not define any equivalence rules for URIs in general as 636 these are defined by the individual URI schemes and by RFC 2396 637 [8]. However, because of inconsistencies with respect to some URI 638 equivalence rules in many current URI parsers, it is STRONGLY 639 RECOMMENDED that generators of DIME messages only rely on the most 640 rudimentary equivalence rules defined by RFC 2396. 642 The size of URIs used as values in the ID field and the TYPE field 643 is limited by the maximum size of these fields which is 2^13-1 644 octets. DIME parsers and generators MUST be able to deal with URIs 645 of this size. 647 4 Internationalization Considerations 649 Identifiers used in DIME such as URIs and MIME media type 650 constructs may provide different levels of support for 651 internationalization. Implementers are referred to RFC 2718 [11] 652 for internationalization consideration of URIs and RFC 2046 [5] for 653 internationalization considerations of MIME media types. 655 5 Security Considerations 657 Implementers should pay special attention to the security 658 implications of any record types that can cause the remote 659 execution of any actions in the recipient's environment. Before 660 accepting records of any type, an application should be aware of 661 the particular security implications associated with that type. 663 Security considerations for media types in general are discussed in 664 RFC 2048 [6] and in the context of the "application/postscript" and 665 the "message/external-body" media type in RFC 2046 [5]. 667 6 IANA Considerations 669 This draft describes a new content type, "application/dime", which 670 must be registered with IANA following the guidelines in RFC 2048 671 [6] (see [15] for the online registration form of media types). 673 7 Intellectual Property 675 The following notice is copied from RFC 2026, Section 10.4, and 676 describes the position of the IETF concerning intellectual property 677 claims made against this document. 679 The IETF takes no position regarding the validity or scope of any 680 intellectual property or other rights that might be claimed to 681 pertain to the implementation or use other technology described in 682 this document or the extent to which any license under such rights 683 might or might not be available; neither does it represent that it 684 has made any effort to identify any such rights. Information on 685 the procedures of the IETF with respect to rights in standards- 686 track and standards-related documentation can be found in BCP-11. 687 Copies of claims of rights made available for publication and any 688 assurances of licenses to be made available, or the result of an 689 attempt made to obtain a general license or permission for the use 690 of such proprietary rights by implementers or users of this 691 specification can be obtained from the IETF Secretariat. 693 The IETF invites any interested party to bring to its attention any 694 copyrights, patents or patent applications, or other proprietary 695 rights that may cover technology that may be required to practice 696 this standard. Please address the information to the IETF Executive 697 Director. 699 8 Acknowledgements 701 Special thanks go to Paul H. Gleichauf and Krishna Sankar of Cisco 702 for their input on this specification. 704 9 References 706 [1] J. B. Postel, "Simple Mail Transfer Protocol", RFC 821, ISI, 707 August 1982 708 [2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 709 1700, October 1994. 710 [3] B. Carpenter, Y. Rekhter, "Renumbering Needs Work", RFC 711 1900, IAB, February 1996 712 [4] S. Bradner, "The Internet Standards Process -- Revision 3", 713 RFC 2026, Harvard University, October 1996 714 [5] N. Freed, N. Borenstein, "Multipurpose Internet Mail 715 Extensions (MIME) Part Two: Media Types" RFC 2046, Innosoft 716 First Virtual, November 1996 717 [6] N. Freed, J. Klensin, J. Postel, "Multipurpose Internet Mail 718 Extensions (MIME) Part Four: Registration Procedures", RFC 719 2048, Innosoft, MCI, ISI, November 1996 720 [7] S. Bradner, "Key words for use in RFCs to Indicate 721 Requirement Levels", RFC 2119, Harvard University, March 722 1997 723 [8] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource 724 Identifiers (URI): Generic Syntax", RFC 2396, MIT/LCS, U.C. 725 Irvine, Xerox Corporation, August 1998. 726 [9] R. Fielding, J. Gettys, J. C. Mogul, H. F. Nielsen, T. 727 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 728 2616, U.C. Irvine, DEC W3C/MIT, DEC, W3C/MIT, W3C/MIT, 729 January 1997 730 [10] R. Petke, I. King, "Registration Procedures for URL Scheme 731 Names", BCP: 35, RFC 2717, UUNET Technologies, Microsoft 732 Corporation, November 1999 733 [11] L. Masinter, H. Alvestrand, D. Zigmond, R. Petke, 734 "Guidelines for new URL Schemes", RFC 2718, Xerox 735 Corporation, Maxware, Pirsenteret, WebTV Networks, Inc., 736 UUNET Technologies, November 1999 737 [12] R. Hinden, B. Carpenter, L. Masinter, "Format for Literal 738 IPv6 Addresses in URL's", RFC 2732, Nokia, IBM, AT&T, 739 December 1999 740 [13] M. Murata, S. St.Laurent, D. Kohn, "XML Media Types" RFC 741 3023, IBM Tokyo Research Laboratory, simonstl.com, Skymoon 742 Ventures, January 2001 743 [14] List of Uniform Resource Identifier (URI) schemes registered 744 by IANA is available at 745 "http://www.iana.org/assignments/uri-schemes" 746 [15] Online form for MIME media type registration 747 http://www.iana.org/cgi-bin/mediatypes.pl 748 10 Authors' Addresses 750 Henrik Frystyk Nielsen 751 Microsoft 752 One Microsoft Way, Redmond, WA 90852 753 Email: henrikn@microsoft.com 755 Henry Sanders 756 Microsoft 757 One Microsoft Way, Redmond, WA 90852 758 Email: henrysa@microsoft.com 760 Erik Christensen 761 Microsoft 762 One Microsoft Way, Redmond, WA 90852 763 Email: erikc@microsoft.com