idnits 2.17.1 draft-aboba-rtp-http-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 181 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 268 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 10 has weird spacing: '...), its areas...' == Line 11 has weird spacing: '... its worki...' == Line 15 has weird spacing: '... and may ...' == Line 19 has weird spacing: '... To learn...' == Line 21 has weird spacing: '...ctories on ...' == (176 more instances...) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0' is mentioned on line 285, but not defined == Missing Reference: '16384' is mentioned on line 286, but not defined == Missing Reference: '32768' is mentioned on line 287, but not defined == Missing Reference: '49152' is mentioned on line 288, but not defined == Missing Reference: '65536' is mentioned on line 288, but not defined == Unused Reference: '1' is defined on line 468, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 471, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 486, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 489, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 499, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1889 (ref. '2') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 1890 (ref. '3') (Obsoleted by RFC 3551) == Outdated reference: A later version (-05) exists of draft-speer-avt-layered-video-01 -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-05) exists of draft-ietf-mhtml-spec-03 == Outdated reference: A later version (-11) exists of draft-ietf-mhtml-info-03 -- Possible downref: Normative reference to a draft: ref. '7' -- Unexpected draft version: The latest known version of draft-ietf-http-v11-spec is -06, but you're referring to -07. == Outdated reference: A later version (-02) exists of draft-crowcroft-rmfp-00 -- Possible downref: Normative reference to a draft: ref. '9' -- Unexpected draft version: The latest known version of draft-parnes-rtp-ext-srm is -00, but you're referring to -01. -- Possible downref: Normative reference to a draft: ref. '10' Summary: 14 errors (**), 0 flaws (~~), 23 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Bernard Aboba 3 Microsoft Corporation 5 Payload Format for HTTP Encoding in RTP 7 1. Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working docu- 10 ments of the Internet Engineering Task Force (IETF), its areas, and 11 its working groups. Note that other groups may also distribute work- 12 ing documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six months 15 and may be updated, replaced, or obsoleted by other documents at any 16 time. It is inappropriate to use Internet-Drafts as reference material 17 or to cite them other than as ``work in progress.'' 19 To learn the current status of any Internet-Draft, please check the 20 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 21 Directories on ds.internic.net (US East Coast), nic.nordu.net 22 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 24 The distribution of this memo is unlimited. It is filed as , and expires July 1, 1997. Please send com- 26 ments to the authors. 28 2. Abstract 30 This document specifies a payload format for use in encoding HTTP 31 within RTP. This payload format can be used for unreliable multicast- 32 ing of resources such as Web pages, stock tickers, etc. As with other 33 RTP applications, receiver feedback and group membership information 34 is provided via RTCP. This specification is not expected to be used 35 with unicast, since unicast applications will instead use HTTP over 36 TCP. 38 3. Introduction 40 3.1. Purpose 42 Considerable interest has recently arisen in the multicasting of 43 resources residing on HTTP servers. Many of these uses can be satis- 44 fied by unreliable multicast transport. 46 In this context, unreliable refers to applications where a repair 47 mechanism is not required. These are typically applications where the 48 material is of time value (stock tickers), so that it makes more sense 49 to wait for the resource to be re-multicast than to attempt to repair 50 it; applications in which an alternative means is available for 51 retrieving the resource (cache filling); applications in which error 52 correction is performed at the datalink layer; or applications in 53 which a separate error correction stream is transmitted along with the 54 data, typically on a separate group. 56 In a cache filling application, there is a relatively small probabil- 57 ity that a particular missing resource will be hit, and so it is often 58 more costly to request a repair than to leave an incompletely received 59 resource in the cache, where it may never be requested. Cache hits 60 when they do occur, will typically be spread out over time, and there- 61 fore not synchronized to the original transmission. As a result, such 62 applications present no danger of a NAK implosion. 64 The encoding specified in this document is not appropriate for use in 65 applications where reliable transmission is required. Such applica- 66 tions present the possibility of a NAK implosion or congestive col- 67 lapse, and so must be carefully analyzed prior to deployment. 69 3.2. Requirements 71 Before discussing the proposed HTTP encoding in RTP, it is useful to 72 describe the requirements for unreliable multicast transmission of 73 resources: 75 Source differentiation 76 Resource demultiplexing 77 Receiver reporting 78 Sender reporting 79 Layered encoding 80 Ability to synchronize with other media 81 Low overhead 83 3.2.1. Source differentiation 85 Since mixing is not useful for transmission of resources, and allowing 86 multiple sources would make it difficult to maintain rate control, it 87 is likely that only one source will be sending to a group at one time. 88 Nevertheless, in the case where there is a handoff, it is necessary to 89 be able to differentiate sources, since packets from the two sources 90 may be intermingled. 92 3.2.2. Resource demultiplexing 94 For multicast resource transmission, it is not desirable to have each 95 resource transmitted with a unique source ID. Resources are typically 96 of small size, and therefore the overhead of obtaining a source ID and 97 setting up the transmission would be excessive. As a result, multiple 98 resources will typically be transmitted with a single source ID. Since 99 it is possible for packets from one resource to become intermingled 100 with another due to out of order delivery, it is necessary to be able 101 to demultiplex resources within a single source ID. 103 3.2.3. Receiver reporting 105 Although the encoding described in this document is to be used only 106 for unreliable transmission, receiver feedback may still be desirable. 107 Such feedback can be used to estimate listenership, packet loss rates, 108 and receiver bandwidth availability. 110 Typically, receiver reporting information will be used both for engi- 111 neering purposes (diagnosis of transmission problems) as well as for 112 business purposes (listenership information). While receiver reports 113 could be useful in allowing senders to adjust transmission parameters, 114 typically it is more desirable to allow receiver-driven rate adapta- 115 tion via layered encoding. 117 By transmitting a resource on several groups, each starting transmis- 118 sion with a different offset, the receiver may adjust their reception 119 rate based on the available bandwidth. Typically, the group transmis- 120 sion rates will be tailored to commonly available bandwidths, i.e. 10 121 Kbps for 14.4 Kbps modems, 20 Kbps for 28.8 Kbps, 30 Kbps for single 122 channel ISDN, etc. 124 Sender-driven transmission rate adjustment appears to be useful in 125 only a limited number of circumstances. In cases where a small frac- 126 tion of listeners are experiencing problems, it is undesirable to 127 adjust the transmission rate; instead, the affected receivers should 128 adjust their rate by leaving the higher bandwidth groups. If this 129 does not work, they should stop listening to the transmission alto- 130 gether. 132 A circumstance in which sender-driven transmission rate adjustment 133 appears useful is in the case where the majority of listeners are only 134 subscribed to the lowest transmission rate group, yet appear to lack 135 the bandwidth to also join an error correction group appropriate to 136 their packet loss rate. In this case the sender should back off the 137 transmission rate on the lowest group to allow for successful recep- 138 tion of the error correction information. 140 As there are applications in which receiver feedback may not be feasi- 141 ble or desirable (satellite transmission), it must be possible to turn 142 off the receiver reporting mechanism if desired. 144 3.2.4. Sender reporting 146 Just as receivers may wish to provide feedback to senders, so may 147 senders wish to provide instructions to receivers. This may include 148 information about the particular resource being transmitted (such as 149 the resource length, related keywords, or URL), or information on the 150 status of the transmission itself, such as the highest offset trans- 151 mitted. 153 3.2.5. Layered encoding 155 Layered multicasting appears to be essential for multicast transmis- 156 sion of resources, since it provides for receiver-driven rate adapta- 157 tion, as well as for transmission of error-correction information. 158 While layered encoding was originally proposed for use in audio/video 159 transmission, it can also be applied to data carousel style transmis- 160 sions. In this application, each of the layers transmits the same 161 resource, beginning at a different offset. Receivers with sufficient 162 bandwidth may then subscribe to multiple groups, and receive the 163 resource more quickly. 165 Layered encoding may also provide for error correction, by allowing 166 error correction information to be transmitted on separate groups. 167 Receivers may then subscribe to these groups according to their aver- 168 age packet loss rate; receivers experiencing high loss rates will typ- 169 ically join a higher bandwidth error correction group. In order to 170 allow for the additional bandwidth of an error correction group, the 171 sender transmission rate should be set appropriately. 173 3.2.6. Ability to synchronize with other media 175 While most uses of unreliable resource multicasting do not have real- 176 time requirements, this may not be true of all such applications. For 177 example, it may be desirable to synchronize display of a resource with 178 an audio/video stream, as in a presentation or lecture, and in such 179 an application it may be desirable to include an encoded clock. 181 3.2.7. Low Overhead 183 Since resource multicasting will typically use a small MTU size (i.e. 184 536 octets), it is important that a low overhead encapsulation be cho- 185 sen. In order to achieve this, the GET request must not be sent in 186 every packet. In addition, it may be desirable to support header com- 187 pression. 189 3.3. Why RTP? 191 Given that RTP was originally created for use in realtime applica- 192 tions, it is not entirely obvious that it is the appropriate protocol 193 to use for resource multicasting. However, given that this applica- 194 tion appears to require receiver and sender reporting, layered encod- 195 ing, and source and resource de-multiplexing, it is likely that an 196 alternative framing will end up more closely resembling RTP than a 197 simple UDP-based approach. 199 Where an alternative encoding would be most likely to differ would be 200 in its reporting mechanisms. For example while the basic header of 201 RMFP, described in [9], bears considerable resemblance to RTP, the 202 sender and receiver packet formats differ considerably from RTCP. 203 However, given the current state of knowledge, it is far from clear 204 that the reporting needs of unreliable resource multicasting differ 205 substantially from those provided by RTCP. 207 Thus while it is not apparent that RTP is the ideal protocol for use 208 in this application, it appears to meet the application requirements. 209 In addition, the behavior of RTP is well understood, and the protocol 210 provides for functions such as RTP monitoring and header compression. 212 3.4. Overview 214 Multicasting of HTTP payloads is useful in a variety of applications, 215 and as a result, several approaches have been taken. One of these is 216 to put a single resource within a payload; another is to pack multiple 217 resources in a payload. If multiple resources are placed within a sin- 218 gle payload, this can be accomplished either via encapsulation or via 219 a packing method such as MHTML, defined in [5]. 221 This document specifies encapsulation of a single resource per pay- 222 load. As defined in this specification, the HTTP payload consists of 223 a preamble header, a MIME-like header, and entity-body content. Infor- 224 mation on the resource being transmitted (such as the URI and the off- 225 set) is placed in the preamble header so as to avoid requiring 226 receivers to parse MIME-headers in the HTTP payload in order to deter- 227 mine what portions of a resource have been received. As a result, this 228 specification does not propose any new MIME headers, and any MIME 229 headers allowable in an HTTP GET response may be enclosed in the pay- 230 load. 232 This simplifies construction of unicast-multicast proxies, since the 233 MIME-like header in the payload can be identical to that returned in 234 the response to an HTTP-GET request. Proxies may therefore make a 235 request for a URL, stuff the response into a payload, and multicast 236 it. This is an efficient process since the proxy does not need to 237 parse the response or construct an MHTML package. 239 4. RTP header 241 Rather than defining a new profile, this specification assumes that 242 HTTP payloads defined in [8] will be transmitted using the RTP profile 243 defined in [3], that is the RTP profile for audio and video conferenc- 244 ing. Additional required parameters are accommodated via definition 245 of an HTTP payload format. As a result, there is no need for header 246 extensions, SDES private extensions, new sender or receiver report 247 fields, new RTCP packet types, or changes in the reporting interval 248 constants. 250 Nevertheless, some clarifications are useful in describing how HTTP 251 payload encoding is to be used with the profile defined in [3]. 253 4.1. Extension bit 255 Although this specification does not preclude use of header exten- 256 sions, it does not define any such extensions, and thus it is expected 257 that the extension bit will typically be cleared. 259 4.2. CSRC count 261 Since HTTP payloads do not require mixing, there is no need for a con- 262 tributing source field. As a result, the CSRC count field is set to 263 zero. 265 4.3. Marker Bit 267 For use with HTTP payloads, a zero marker bit is used to indicate the 268 last packet for a resource. The first packet is distinguished by a 269 zero offset, and as a result, does not need to be marked. 271 4.4. Payload types 273 A dynamic payload type in the range of 96-128 is used. The binding of 274 payload type and application is accomplished by non-RTP means, such as 275 use of the "m=" and "a=" fields of the session description: 277 m=data 32768 RTP/AVP 98 278 a=rtpmap: 98 MHTTP 280 4.5. Port numbers 282 Although there is no official policy on this, current practice dic- 283 tates usage of port ranges as follows: 285 [0, 16384] - lowest priority, unclassified 286 [16384, 32768] - highest priority, i.e. audio 287 [32768, 49152] - medium priority, i.e. whiteboard 288 [49152, 65536] - low priority, i.e. video 290 It is recommended that unreliable multicast HTTP use the medium prior- 291 ity port range. 293 4.6. SSRC 295 Unlike with A/V payloads, a sender may use a single synchronization 296 source for transmission of multiple HTTP payload streams. Thus a JPEG 297 file may be transmitted with the same SSRC as an HTML file. This does 298 not present a problem since the timestamp is used to uniquely identify 299 resource streams. 301 4.7. Timestamp 303 Since a single synchronization source is used for transmission of mul- 304 tiple resources, an additional parameter is needed to identify packets 305 within the same resource. The URI was not felt to be sufficient for 306 this purpose, since a given resource may be multicast in data-carousel 307 style, changing with each transmission. 309 As a result, the RTP timestamp field is used for this purpose. For 310 use with HTTP payloads, the timestamp is constant for all packets that 311 form a single transmission of a resource, and represents the time at 312 which the sender began to transmit the resource. 314 Due to out of order delivery it is possible that packets from one 315 resource will be intermingled with packets from another resource, sent 316 to the same group and port. In this case the combination of the SSRC 317 and timestamp can be used to demultiplex the resource stream. 319 5. HTTP Payload format 321 HTTP payloads consist of a preamble header, a MIME-like header, and 322 entity-body content. 324 The purpose of the preamble header is identify the resource being 325 sent. Depending on the caching implementation, partially received 326 resources will either be discarded, or will be appropriately marked 327 for storage in the cache. This will allow the cache to request the 328 missing portion of the resource if a cache hit occurs. 330 Since this specification is primarily intended for use in situations 331 where a local repair may not be timely (such as with a frequently 332 updated stock ticker), where the resource will be re-multicast, or 333 where error correction information is transmitted on a separate group, 334 no repair mechanism is required. 336 While MIME-like headers could be used for resource identification (to 337 provide information such as the URI, referring URI, content length and 338 content range), prepending of a binary header reduces the amount of 339 parsing required to get at this critical information. The use of a 340 preamble header has the additional benefit of not requiring MIME-like 341 headers to be present other than in the first packet. Thus, subsequent 342 packets will typically contain only the preamble header and body con- 343 tent. 345 Thus, rather than adding MIME-like headers, it is intended that 346 senders will simply retransmit the MIME-like header obtained in the 347 HTTP GET response. Similarly, it is expected that the entity-body con- 348 tent will be retransmitted without modification. 350 5.1. Preamble header 352 The preamble header is comprised of an 8 octet fixed portion, and a 353 single variable-length string. 355 1 2 3 356 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | | 359 | Offset (8 octets) | 360 | | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | GET request... 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | GET request.... |0| 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 5.1.1. Offset 369 The offset field is 64-bits long. For a data packet, it represents the 370 octet offset within the resource identified by the RTP timestamp. 371 Although the offset field will typically increase with increasing 372 sequence numbers, this need not always be the case, since portions of 373 a resource may be transmitted out of order. Receivers should therefore 374 be prepared to handle packet ordering based on the offset rather than 375 the sequence number. 377 While the offset information could have also been provided using the 378 Content-range: HTTP response header, this would have required inser- 379 tion of a MIME-like header within each packet, and parsing of this 380 header by the receiver. It is felt that the offset mechanism is more 381 efficient. 383 5.1.2. GET request 385 The GET request field is a null-terminated string, representing the 386 full text of the GET request that caused the resource to be transmit- 387 ted. At a minimum, the GET request, defined in [8], includes the GET 388 method, the URI and the HTTP version. While it begins on a 32-bit 389 boundary, the GET request field is not padded to such a boundary. 391 Given the expected size of the GET request field, this variable-length 392 string is expected to comprise the majority of the encapsulation over- 393 head. Given that the string may be 40 octets or larger, when the 40 394 octets of IP/UDP/RTP header are added, the result may be 80 octets or 395 more of overhead. This level of overhead would be unacceptable if it 396 were present in every packet. 398 The GET request, offset, and packet length uniquely identify the por- 399 tion of the resource being transmitted. Since receivers may join late, 400 or miss portions of the transmission, receivers must be able to 401 quickly bind a timestamp to a GET request so that the incoming 402 resource and missing portions can be identified. 404 However, it is believed that this goal can be accomplished by placing 405 the GET request within the first packet of a series, and then only 406 within every subsequent nth packet. This results in a substantial 407 reduction in overhead. For the purposes of this specification, it is 408 suggested that n=4. 410 For packets in which the GET request is not included, a single null 411 octet is used to indicate the missing field. 413 6. Resource length 415 The resource length is not included in the preamble header. Typically, 416 this information is included within the first packet via the Content- 417 length: header. Although it is possible that the first and/or final 418 packet will be lost, we do not believe that the resource length justi- 419 fies inclusion within the preamble header. This is because it is not 420 necessary to know the total length of the resource to make a partial 421 GET request for the remainder of the resource should a cache hit 422 occur. 424 Note that it is possible that the final packets of a resource are 425 lost. In this case, the receiver will note that it has not yet 426 received a packet with the marker bit indicating completion of the 427 resource transmission, after waiting a suitable interval after recep- 428 tion of the last packet. After this interval has expired, the receiver 429 will write the incomplete resource out to the disk. 431 7. Non-RTP means 433 In addition to information transmitted within the RTP encoding, it is 434 expected that receivers will make use of session information transmit- 435 ted by non-RTP means. 437 For example, the existence of a data-carousel style session is 438 expected to be determined via SDP, transmitted in one of its encapsu- 439 lations, such as SAP. The SDP announcement will provide information on 440 the bandwidth allocated to the session, as well as the group address 441 (or in the case of a multi-group session, addresses) allocated to the 442 session. 444 The SDP announcement will also be expected to indicate whether the 445 data carousel transmission provides for re-multicast of the same 446 resource (in which case receivers can make partial GET requests for 447 the missing portion), or whether it provides continually updated 448 information (in which case receivers missing a portion of the resource 449 should make a GET request for the entire resource). 451 8. Layered encoding 453 Reference [4] discusses use of RTP in layered multicasting, and pro- 454 poses guidelines for group address and port allocation, as well as 455 modifications to RTP semantics suitable for allocation of SSRC identi- 456 fiers across layered streams. SDES packets are then sent only on the 457 lowest layer. It is expected that these modifications, once available, 458 should be applicable to transmission of layered HTTP payloads. 460 9. Acknowledgements 462 Thanks to Peter Parnes of the University of Lulea, and Jim Gemmell, 463 Paul Leach and Thomas Pfenning of Microsoft for useful discussions of 464 this problem space. 466 10. References 468 [1] R. Braden. "Requirements for Internet hosts - application and 469 support." STD 3, RFC 1123, IETF, October 1989. 471 [2] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. "RTP: A 472 Transport Protocol for Real-Time Applications." RFC 1889, GMD Fokus, 473 January 1996. 475 [3] H. Schulzrinne. "RTP Profile for Audio and Video Conferences 476 with Minimal Control." RFC 1890, GMD Fokus, January 1996. 478 [4] M. F. Speer, S. McCanne. "RTP Usage with Layered Multimedia 479 Streams." draft-speer-avt-layered-video-01.txt, Sun Microsystems, 480 LBNL, June 1996. 482 [5] J. Palme, A. Hopmann. "MIME E-mail Encapsulation of Aggregate 483 Documents, such as HTML (MHTML)." draft-ietf-mhtml-spec-03.txt, 484 Stockholm University/KTH, ResNova Software, August, 1996. 486 [6] E. Levinson. "The MIME Multipart/Related Content-type." draft- 487 ietf-mhtml-related-00.txt, Xison, May, 1996. 489 [7] J. Palme. "Sending HTML in E-mail, an informational supplement." 490 draft-ietf-mhtml-info-03.txt, Stockholm University/KTH, August, 1996. 492 [8] R. Fielding, et al. "Hypertext Transfer Protocol - HTTP/1.1." 493 draft-ietf-http-v11-spec-07, UC Irvine, August, 1996. 495 [9] J. Crowcroft, Z. Wang, A. Ghosh, C. Diot. "RMFP: A Reliable Mul- 496 ticast Framing Protocol." draft-crowcroft-rmfp-00.txt, UCL, November, 497 1996. 499 [10] P. Parnes. "RTP Extension for Scalable Reliable Multicast." 500 draft-parnes-rtp-ext-srm-01.txt, LuTH/CDT, November, 1996. 502 11. Authors' Addresses 504 Bernard Aboba 505 Microsoft Corporation 506 One Microsoft Way 507 Redmond, WA 98052 509 Phone: 206-936-6605 510 EMail: bernarda@microsoft.com