idnits 2.17.1 draft-aboba-rtp-http-01.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 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 111 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 182 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 ...' == (106 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 317, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 320, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 335, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 338, 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 10, 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. 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 a payload; another is to pack multiple 56 resources in a payload. If multiple resources are placed within a sin- 57 gle payload, this can be accomplished either via encapsulation or via 58 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 propose 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 payload can be identical to that returned in 73 the response to an HTTP-GET request. Proxies may therefore make a 74 request for a URL, stuff the response into a payload, and multicast 75 it. This is an efficient process since the proxy does not need to 76 parse the response or construct an MHTML package. 78 4. RTP header 80 Rather than defining a new profile, this specification assumes that 81 HTTP payloads will be transmitted using the RTP profile defined in 82 [3], that is the RTP profile for audio and video conferencing. Addi- 83 tional required parameters are accommodated via definition of an HTTP 84 payload format. As a result, there is no need for header extensions, 85 SDES private extensions, new sender or receiver report fields, new 86 RTCP packet types, or changes in the reporting interval constants. 88 Nevertheless, some clarifications are useful in describing how HTTP 89 payload encoding is to be used with the profile defined in [3]. 91 4.1. Extension bit 93 Since this specification does not define header extensions for encod- 94 ing of HTTP payloads, the extension bit will typically be cleared. 96 4.2. CSRC count 98 Since HTTP payloads do not require mixing, there is no need for a con- 99 tributing source field. As a result, the CSRC count field is set to 100 zero. 102 4.3. Marker Bit 104 For use with HTTP payloads, a zero marker bit is used to indicate the 105 last packet for a resource. The first packet is distinguished by 106 inclusion of a MIME -like header after the preamble header. 108 4.4. Payload types 110 A dynamic payload type is used. As a result, there is no need to 111 assign a static payload type. 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 an HTML 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. 153 Therefore repairs are expected to be executed via a partial HTTP GET 154 request. 156 While MIME-like headers could be used for resource identification (to 157 provide information such as the URI, referring URI, content length and 158 content range), prepending of a binary header reduces the amount of 159 parsing required to get at this critical information. The use of a 160 preamble header has the additional benefit of not requiring MIME-like 161 headers to be present other than in the first packet. Thus, subsequent 162 packets will typically contain only the preamble header and body con- 163 tent. 165 Thus, rather than adding MIME-like headers, it is intended that 166 senders will simply retransmit the MIME-like header obtained in the 167 HTTP GET response. Similarly, it is expected that the entity-body con- 168 tent will be retransmitted without modification. 170 5.1. Preamble header 172 The preamble header is comprised of a 4 octet fixed portion, and two 173 variable-length strings. 175 1 2 3 176 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 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Offset | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | URI |0| 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | URI |0| Referring URI |0| 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 5.1.1. Offset 187 The offset field is 32-bits long. For a data packet, it represents the 188 octet offset within the resource identified by the RTP timestamp. 189 Although the offset field will typically increase with increasing 190 sequence numbers, this need not always be the case, since portions of 191 a resource may be transmitted out of order. Receivers should therefore 192 be prepared to handle packet ordering based on the offset rather than 193 the sequence number. 195 While the offset information could have also been provided using the 196 Content-range: HTTP response header, this would have required inser- 197 tion of a MIME-like header within each packet, and parsing of this 198 header by the receiver. It is felt that the offset mechanism is more 199 efficient. 201 5.1.2. URI 203 The URI field is a null-terminated string, representing the URI of the 204 resource being transmitted. While it begins on a 32-bit boundary, it 205 is not padded to such a boundary. 207 Given the expected size of the URI and referring URI fields, the vari- 208 able-length strings are expected to comprise the vast majority of the 209 preamble header. Given that each of the string fields may be 40 octets 210 or larger in length, when the 28 octets of IP/UDP header and 12 octets 211 of RTP header are added, the result may be 140 octets or more of over- 212 head. This amount of overhead would be unacceptable if it were present 213 in every packet. It is therefore appropriate to ask whether the URI 214 and referring URI fields are required for inclusion within every 215 packet. 217 The URI, offset, and packet length uniquely identify the portion of 218 the resource being transmitted. Since receivers may join late, or miss 219 portions of the transmission, receivers must be able to quickly bind a 220 timestamp to a URI so that the incoming resource and missing portions 221 can be identified. 223 However, it is believed that this goal can be accomplished by placing 224 the URI within the first packet of a series, and then only within 225 every subsequent nth packet. This results in a substantial reduction 226 in overhead. For the purposes of this specification, it is suggested 227 that n=4. 229 For packets in which the URI is not included, a single null octet is 230 used to indicate the missing field. 232 5.1.3. Referring URI 234 The referring URI field is a null-terminated string, representing the 235 URI of the resource referring to the resource being transmitted. It 236 begins immediately after the null signifying the end of the URI field, 237 and is not padded to a 32-bit boundary. 239 The referring URI is used to identify the resource referring to the 240 resource being transmitted. This is used by late joining receivers 241 wishing to retrieve the context of the current transmission. Typi- 242 cally this is done via an HTTP GET request. However, in the case of 243 data-carousel transmission, this is not necessary, since the referring 244 resource will be re-transmitted at a later time. 246 As with the URI, the referring URI should not be transmitted within 247 every packet. Instead, it should be placed within the first packet of 248 a series, and then transmitted every 2n packets. 250 For packets in which the referring URI is not included, a single null 251 octet is used to indicate the missing field. 253 6. Resource length 255 The resource length is not included in the preamble header. Typically, 256 this information is included within the first packet via the Content- 257 length: header. Although it is possible that the first and/or final 258 packet will be lost, we do not believe that the resource length justi- 259 fies inclusion within the preamble header. This is because the 260 receiver need not know the total length of the resource to make a par- 261 tial GET request for the remainder of the resource. 263 Note that it is possible that the final packets of a resource are 264 lost. In this case, the receiver will note that it has not yet 265 received a packet with the marker bit indicating completion of the 266 resource transmission, after waiting a suitable interval after recep- 267 tion of the last packet. This interval is determined by the receiver's 268 estimate of his RTT to the sender. After this interval has expired, 269 the receiver will either wait for the re-multicasting of the resource, 270 or will attempt to retrieve the missing portion via a partial HTTP 271 GET. 273 7. Layered Data Carousels 275 Reference [4] discusses use of RTP in layered multicasting. Layered 276 multicasting provides for receiver-driven rate adaptation. While this 277 was originally proposed for use in transmission of audio and video, it 278 can also be applied to data carousel style transmissions. In this 279 application, each of the layers transmits the same resource, beginning 280 at a different offset. Receivers with sufficient bandwidth may then 281 subscribe to multiple groups, and receive the resource more quickly. 283 Reference [4] proposes guidelines for group address and port alloca- 284 tion, as well as modifications to RTP semantics suitable for alloca- 285 tion of SSRC identifiers across layered streams. SDES packets are then 286 sent only on the lowest layer. It is expected that these modifica- 287 tions, once available, should be applicable to transmission of layered 288 HTTP payloads. 290 8. Non-RTP means 292 In addition to information transmitted within the RTP encoding, it is 293 expected that receivers will make use of session information transmit- 294 ted by non-RTP means. 296 For example, the existence of a data-carousel style session is 297 expected to be determined via SDP, transmitted in one of its encapsu- 298 lations, such as SAP. The SDP announcement will provide information on 299 the bandwidth allocated to the session, as well as the group address 300 (or in the case of a multi-group session, addresses) allocated to the 301 session. 303 The SDP announcement will also be expected to indicate whether the 304 data carousel transmission provides for re-multicast of the same 305 resource (in which case receivers can make partial GET requests for 306 the missing portion), or whether it provides continually updated 307 information (in which case receivers missing a portion of the resource 308 should make a GET request for the entire resource). 310 9. Acknowledgements 312 Thanks to Peter Parnes of the University of Lulea, and Thomas Pfenning 313 of Microsoft for useful discussions of this problem space. 315 10. References 317 [1] R. Braden. "Requirements for Internet hosts - application and 318 support." STD 3, RFC 1123, IETF, October 1989. 320 [2] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. "RTP: A 321 Transport Protocol for Real-Time Applications." RFC 1889, GMD Fokus, 322 January 1996. 324 [3] H. Schulzrinne. "RTP Profile for Audio and Video Conferences 325 with Minimal Control." RFC 1890, GMD Fokus, January 1996. 327 [4] M. F. Speer, S. McCanne. "RTP Usage with Layered Multimedia 328 Streams." draft-speer-avt-layered-video-01.txt, Sun Microsystems, 329 LBNL, June 1996. 331 [5] J. Palme, A. Hopmann. "MIME E-mail Encapsulation of Aggregate 332 Documents, such as HTML (MHTML)." draft-ietf-mhtml-spec-03.txt, 333 Stockholm University/KTH, ResNova Software, August, 1996. 335 [6] E. Levinson. "The MIME Multipart/Related Content-type." draft- 336 ietf-mhtml-related-00.txt, Xison, May, 1996. 338 [7] J. Palme. "Sending HTML in E-mail, an informational supplement." 339 draft-ietf-mhtml-info-03.txt, Stockholm University/KTH, August, 1996. 341 11. Authors' Addresses 343 Bernard Aboba 344 Microsoft Corporation 345 One Microsoft Way 346 Redmond, WA 98052 348 Phone: 206-936-6605 349 EMail: bernarda@microsoft.com