idnits 2.17.1 draft-aboba-rtp-http-00.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-25) 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 7 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 7 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 115 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 181 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 ...' == (110 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) == Unused Reference: '1' is defined on line 315, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 318, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 333, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 336, 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' Summary: 14 errors (**), 0 flaws (~~), 16 warnings (==), 4 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 May 1, 1997. Please send comments 26 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. 36 3. Introduction 38 3.1. Purpose 40 Considerable interest has recently arisen in the multicasting of 41 resources residing on HTTP servers. Many of these uses can be satis- 42 fied by ureliable transmission. 44 This document specifies a payload format suitable for encoding of HTTP 45 within RTP. It is expected that this payload format will prove useful 46 for unreliable multicasting of resources, either on a one-shot basis, 47 or in a data carousel-style format, where resources are continually 48 re-multicast. This specification is not expected to be used with uni- 49 cast, since unicast applications will instead use HTTP over TCP. 51 3.2. Overview 53 Multicasting of HTTP payloads is useful in a variety of applications, 54 and as a result, several approaches have been taken. One of these is 55 to put a single resource within an RTP payload; another is to pack 56 multiple resources in a payload. If multiple resources are placed 57 within a single payload, this can be accomplished either via encapsu- 58 lation or via a packing method such as MHTML, defined in [5]. 60 This document specifies encapsulation of a single resource per pay- 61 load. As defined in this specification, the HTTP payload consists of 62 a preamble header, a MIME-like header, and entity-body content. Infor- 63 mation on the resource being transmitted (such as the URI and the off- 64 set) is placed in the preamble header so as to avoid requiring 65 receivers to parse MIME-headers in the HTTP payload in order to deter- 66 mine what portions of a resource have been received. As a result, this 67 specification does not proposed any new MIME headers, and any MIME 68 headers allowable in an HTTP GET response may be enclosed in the pay- 69 load. 71 This simplifies construction of unicast-multicast proxies, since the 72 MIME-like header in the RTP payload can be identical to that returned 73 in the response to an HTTP-GET request. Proxies may therefore make a 74 request for a URL and associated links, stuff the responses into RTP 75 payload, and multicast them. This is an efficient process since the 76 proxy does not need to parse the response or construct an MHTML pack- 77 age. 79 4. RTP data header 81 Rather than defining a new profile, this specification assumes that 82 HTTP payloads will be transmitted using the RTP profile defined in 83 [3], that is the RTP profile for audio and video conferencing. Addi- 84 tional required parameters are accommodated via definition of an HTTP 85 payload format. As a result, there is no need for header extensions, 86 SDES private extensions, new sender or receiver report fields, new 87 RTCP packet types, or changes in the reporting interval constants. 89 Nevertheless, some clarifications are useful in describing how HTTP 90 payload encoding is to be used with the profile defined in [3]. 92 4.1. Extension bit 94 Since this specification does not define header extensions for encod- 95 ing of HTTP payloads, the extension bit will typically be cleared. 97 4.2. CSRC count 99 Since HTTP payloads do not require mixing, there is no need for a con- 100 tributing source field. As a result, the CSRC count field is set to 101 zero. 103 4.3. Marker Bit 105 For use with HTTP payloads, a zero marker bit is used to indicate the 106 last packet for a resource. This first packet is distinguished by 107 inclusion of a MIME -like header after the preamble header. 109 4.4. Payload types 111 A dynamic payload type is used. 113 4.5. SSRC 115 Unlike with A/V payloads, a sender may use a single synchronization 116 source for transmission of multiple HTTP payload streams. Thus a JPEG 117 file may be transmitted with the same SSRC as a text file. This does 118 not present a problem since the timestamp is used to uniquely identify 119 resource streams. 121 4.6. Timestamp 123 Since a single synchronization source is used for transmission of mul- 124 tiple resources, an additional parameter is needed to identify packets 125 within the same resource. The URI was not felt to be sufficient for 126 this purpose, since a given resource may be multicast in data-carousel 127 style, changing with each transmission. 129 As a result, the RTP timestamp field is used for this purpose. For 130 use with HTTP payloads, the timestamp is constant for all packets that 131 form a single transmission of a resource, and represents the time at 132 which the sender began to transmit the resource. 134 Due to out of order delivery it is possible that packets from one 135 resource will be intermingled with packets from another resource, sent 136 to the same group and port. In this case the combination of the SSRC 137 and timestamp can be used to demultiplex the resource stream. 139 5. HTTP Payload format 141 HTTP payloads consist of a preamble header, a MIME-like header, and 142 entity-body content. 144 The purpose of the preamble header is identify the resource being 145 sent, and to allow late joining receivers to calculate which portion 146 of the resource they have missed. Depending on the application, 147 resources with missing portions will either be discarded or a repair 148 request will be made. Since this specification is primarily intended 149 for use in situations where a local repair may not be timely (such as 150 with a frequently updated stock ticker), or where the resource will be 151 re-multicast, it is not clear that an RTCP "NAK" packet is needed. 152 Therefore repairs are expected to be executed via a partial HTTP GET 153 request. 155 While MIME-like headers could be used for resource identification (to 156 provide information such as the URI, referring URI, content length and 157 content range), prepending of a binary header reduces the amount of 158 parsing required to get at this critical information. The use of a 159 preamble header has the additional benefit of not requiring MIME-like 160 headers to be present other than in the first packet. Thus, subsequent 161 packets will typically contain only the preamble header and body con- 162 tent. 164 Thus, rather than adding MIME-like headers, it is intended that 165 senders will simply retransmit the MIME-like header obtained in the 166 HTTP GET response. Similarly, it is expected that the entity-body con- 167 tent will be retransmitted without modification. 169 5.1. Preamble header 171 The preamble header is comprised of a 4 octet fixed portion, and two 172 variable-length strings. 174 1 2 3 175 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 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Offset | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | URI |0| 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | URI |0| Referring URI |0| 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 5.1.1. Offset 186 The offset field is 32-bits long. For a data packet, it represents the 187 octet offset within the resource identified by the session ID. 188 Although the offset field will typically increase with increasing 189 sequence numbers, this need not always be the case, since portions of 190 a resource may be transmitted out of order. Receivers should therefore 191 be prepared to handle packet ordering based on the offset rather than 192 the sequence number. 194 While the offset information could have also been provided using the 195 Content-range: HTTP response header, this would have required inser- 196 tion of a MIME-like header within each packet, and parsing of this 197 header by the receiver. It is felt that the offset mechanism proposed 198 here is more efficient. 200 5.1.2. URI 202 The URI field is a null-terminated string, representing the URI of the 203 resource being transmitted. While it begins on a 32-bit boundary, it 204 is not padded to such a boundary. 206 Given the expected size of the URI and referring URI fields, the vari- 207 able-length strings are expected to comprise the vast majority of the 208 preamble header. Given that each of the string fields may be 40 octets 209 or larger in length, when the 28 octets of IP/UDP header and 12 octets 210 of RTP header are added, the result may be 140 octets or more of over- 211 head. This amount of overhead would be unacceptable if it were present 212 in every packet. It is therefore appropriate to ask whether the URI 213 and referring URI fields are required for inclusion within every 214 packet. 216 The URI, offset, and packet length uniquely identify the portion of 217 the resource being transmitted. Since receivers may join late, or miss 218 portions of the transmission, receivers must be able to quickly bind a 219 session ID to a URI so that the incoming resource and missing portions 220 can be identified. 222 However, it is believed that this goal can be accomplished by placing 223 the URI within the first packet of a series, and then only within 224 every subsequent nth packet. This results in a substantial reduction 225 in overhead. For the purposes of this specification, it is suggested 226 that n=4. 228 For packets in which the URI is not included, a single null octet is 229 used to indicate the missing field. 231 5.1.3. Referring URI 233 The referring URI field is a null-terminated string, representing the 234 URI of the resource referring to the resource being transmitted. It 235 begins immediately after the null signifying the end of the URI field, 236 and is padded to a 32-bit boundary. 238 The referring URI is used to identify the resource referring to the 239 resource being transmitted. This is used by late joining receivers 240 wishing to retrieve the context of the current transmission. Typi- 241 cally this is done via an HTTP GET request. However, in the case of 242 data-carousel transmission, this is not necessary, since the referring 243 resource will be re-transmitted at a later time. 245 As with the URI, the referring URI should not be transmitted within 246 every packet. Instead, it should be placed within the first packet of 247 a series, and then transmitted every 2n packets. 249 For packets in which the referring URI is not included, a single null 250 octet is used to indicate the missing field. 252 6. Resource length 254 The resource length is not included in the preamble header. Typically, 255 this information is included within the first packet via the Content- 256 length: header. Although it is possible that the first and/or final 257 packet will be lost, we do not believe that the resource length justi- 258 fies inclusion within the preamble header. This is because the 259 receiver need not know the total length of the resource to make a par- 260 tial GET request for the remainder of the resource. 262 Note that it is possible that the final packets of a resource is lost. 263 In this case, the receiver will note that it has not yet received a 264 packet with the marker bit indicating completion of the resource 265 transmission, after waiting a suitable interval after reception of the 266 last packet. This interval is determined by the receiver's estimate of 267 his RTT to the sender. After this interval has expired, the receiver 268 will either wait for the re-multicasting of the resource, or will 269 attempt to retrieve the missing portion via a partial HTTP GET. 271 7. Layered Data Carousels 273 Reference [4] discusses use of RTP in layered multicasting. Layered 274 multicasting provides for receiver-driven rate adaptation. While this 275 was originally proposed for use in transmission of audio and video, it 276 can also be applied to data carousel style transmissions. In this 277 application, each of the layers transmits the same resource, beginning 278 at a different offset. Receivers with sufficient bandwidth may then 279 subscribe to multiple groups, and receive the resource more quickly. 281 Reference [4] proposes guidelines for group address and port alloca- 282 tion, as well as modifications to RTP semantics suitable for alloca- 283 tion of SSRC identifiers across layered streams. SDES packets are then 284 sent only on the lowest layer. It is expected that these modifica- 285 tions, once available, should be applicable to transmission of layered 286 HTTP payloads. 288 8. Non-RTP means 290 In addition to information transmitted within the RTP encoding, it is 291 expected that receivers will make use of session information transmit- 292 ted by non-RTP means. 294 For example, the existence of a data-carousel style session is 295 expected to be determined via SDP, transmitted in one of its encod- 296 ings, such as SAP. The SDP announcement will provide information on 297 the bandwidth allocated to the session, as well as the group address 298 (or in the case of a multi-group session, addresses) allocated to the 299 session. 301 The SDP announcement will also be expected to indicate whether the 302 data carousel transmission provides for re-multicast of the same 303 resource (in which case receivers can make partial GET requests for 304 the missing portion), or whether it provides continually updated 305 information (in which case receivers missing a portion of the resource 306 should make a GET request for the entire resource). 308 9. Acknowledgements 310 Thanks to Peter Parnes of the University of Lulea, and Thomas Pfenning 311 of Microsoft for useful discussions of this problem space. 313 10. References 315 [1] R. Braden. "Requirements for Internet hosts - application and 316 support." STD 3, RFC 1123, IETF, October 1989. 318 [2] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. "RTP: A 319 Transport Protocol for Real-Time Applications." RFC 1889, GMD Fokus, 320 January 1996. 322 [3] H. Schulzrinne. "RTP Profile for Audio and Video Conferences 323 with Minimal Control." RFC 1890, GMD Fokus, January 1996. 325 [4] M. F. Speer, S. McCanne. "RTP Usage with Layered Multimedia 326 Streams." draft-speer-avt-layered-video-01.txt, Sun Microsystems, 327 LBNL, June 1996. 329 [5] J. Palme, A. Hopmann. "MIME E-mail Encapsulation of Aggregate 330 Documents, such as HTML (MHTML)." draft-ietf-mhtml-spec-03.txt, 331 Stockholm University/KTH, ResNova Software, August, 1996. 333 [6] E. Levinson. "The MIME Multipart/Related Content-type." draft- 334 ietf-mhtml-related-00.txt, Xison, May, 1996. 336 [7] J. Palme. "Sending HTML in E-mail, an informational supplement." 337 draft-ietf-mhtml-info-03.txt, Stockholm University/KTH, August, 1996. 339 11. Authors' Addresses 341 Bernard Aboba 342 Microsoft Corporation 343 One Microsoft Way 344 Redmond, WA 98052 346 Phone: 206-936-6605 347 EMail: bernarda@microsoft.com