idnits 2.17.1 draft-blackketter-uhttp-00.txt: 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-19) 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: ---------------------------------------------------------------------------- == 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 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 457: '...ze HTTP-style headers MUST contain the...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 385 has weird spacing: '...rection is us...' -- 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 (February 11, 2000) is 8834 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: '4' is defined on line 579, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. '1' -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2068 (ref. '5') (Obsoleted by RFC 2616) -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D.J. Blackketter 2 Internet-Draft WebTV Networks, Inc. 3 Expires: August 11, 2000 February 11, 2000 5 The Unidirectional Hypertext Transfer Protocol 6 draft-blackketter-uhttp-00.txt 8 Status of this Memo 10 This document is an Internet-Draft and is NOT offered in accordance 11 with Section 10 of RFC2026, and the author does not provide the IETF 12 with any rights other than to publish as an Internet-Draft. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on August 11, 2000. 32 Abstract 34 This document describes the Unidirectional Hypertext Transfer 35 Protocol, or UHTTP. UHTTP is a simple, robust, one-way data transfer 36 protocol that is designed to efficiently deliver resource data in a 37 one-way broadcast-only environment. This transfer protocol is 38 appropriate for delivery of HTML and other content resources using 39 IP multicast over television vertical blanking interval (IP/VBI) and 40 other unidirectional transport systems. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. Data Transfer Features Enabled by the UHTTP Protocol . . . . 4 46 2.1 Robust Delivery: Gathering data over multiple transmissions 4 47 2.2 Meta-information in the form of HTTP-style headers . . . . . 4 48 3. UHTTP Header Format . . . . . . . . . . . . . . . . . . . . 5 49 3.1 Basic UHTTP Header Format . . . . . . . . . . . . . . . . . 5 50 3.2 UHTTP Extension Header Format . . . . . . . . . . . . . . . 7 51 3.2.1 HTTPHeaderMap Extension Header . . . . . . . . . . . . . . . 8 52 4. Forward Error Correction Mechanism . . . . . . . . . . . . . 11 53 5. HTTP-style headers used in UHTTP . . . . . . . . . . . . . . 13 54 5.1 Supported HTTP-style headers . . . . . . . . . . . . . . . . 13 55 6. Packaging more than one resource . . . . . . . . . . . . . . 15 56 7. Security Considerations . . . . . . . . . . . . . . . . . . 17 57 References . . . . . . . . . . . . . . . . . . . . . . . . . 18 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . 18 59 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 61 1. Introduction 63 The Unidirectional Hypertext Transfer Protocol, or UHTTP, is a 64 simple, robust data transfer protocol that is designed to 65 efficiently deliver resource data in a one-way broadcast-only 66 environment. This transfer protocol is appropriate for delivery of 67 HTML and other content resources using IP multicast over television 68 vertical blanking interval (IP/VBI) and other unidirectional 69 transport systems. The UHTTP protocol is used in the Advanced 70 Television Enhancement Forum specification[6] to deliver 71 television-related content resources which were broadcast along with 72 a television signal. 74 Resources sent using the UHTTP protocol are divided into a set of 75 data segments encapsulated in UDP packets. Typically, these packets 76 are delivered via multicast IP, but this is not required. Each 77 packet contains enough header information to begin capturing the 78 data at any time during the broadcast, even midway through the 79 transfer. This header contains a unique identifier (in the form of 80 an UUID[1]) that uniquely identifies the transfer, and additional 81 information that enables the receiver to place the data following 82 the header in the appropriate location within the transfer. 83 Additional header information indicates to the receiver how long to 84 continue listening for additional data. 86 UHTTP includes the ability to gather segments over multiple 87 retransmissions to correct for missing packets. It is also possible 88 to group resources together for all-or-none delivery within a UHTTP 89 transfer. The protocol also includes a simple forward error 90 correcting mechanism which provides for the ability to restore 91 missing data in the event of limited packet loss. 93 2. Data Transfer Features Enabled by the UHTTP Protocol 95 2.1 Robust Delivery: Gathering data over multiple transmissions 97 Data can be resent via UHTTP using the same globally unique 98 TransferID. The data is delivered as individual segments, each of 99 which is encapsulated within a UDP message, potentially delivered 100 via IP multicast. Information in the header allows a receiving 101 application to receive segments out of order or multiple times. If 102 the transfer data is sent repeatedly, the receiving service can fill 103 in missing ranges using these retransmissions. This provides robust 104 (though not necessarily reliable) data delivery. Additionally, 105 forward error correction (FEC), using an exclusive-or-based 106 algorithm, provides for recovery of some missing segments in the 107 face of segment loss without retransmission. 109 2.2 Meta-information in the form of HTTP-style headers 111 The protocol provides for the inclusion of HTTP-style headers 112 preceding the resource data. These headers may include information 113 describing the content type of the resource and content location in 114 the form of a URL. It may also be used to describe groups of 115 resources as a multipart construction. Other meta-information, 116 including date stamping and expiration dates, may be used to provide 117 additional information about the resource content. 119 3. UHTTP Header Format 121 3.1 Basic UHTTP Header Format 123 This section describes the format of the message packets that carry 124 UHTTP data. It describes the information needed to create the 125 messages using the protocol on the broadcast side and to turn those 126 messages back into resources on the receiving side. 128 The UHTTP header is at the start of every UHTTP IP/UDP datagram. All 129 values are network byte order. 131 The UHTTP header has the following format: 133 0 1 2 3 134 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 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | version |X|H|C| PcktsInXORBlk | retransmit expiration | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | | 139 +- -+ 140 | | 141 +- transfer ID -+ 142 | | 143 +- -+ 144 | | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | resource size | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | segment start offset | 149 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=| 150 | payload or extension header | 151 : .... : 153 The fields are described below. 155 Version : 5 bits 157 Describes the version of the protocol. The protocol described 158 here is version 0. 160 Extension Header (X) : 1 bit 162 When set, this bit indicates that one or more extension header 163 fields are present and immediately follow the main UHTTP header. 165 HTTP Headers Precede (H) : 1 bit 166 A bit flag that, when set to 1, indicates that HTTP-style headers 167 precede the resource data. These HTTP-style headers are 168 considered part of the data when calculating the ResourceSize and 169 SegStartByte fields, as well as for forward error correction. 170 This bit must be set in all packets associated with a UHTTP 171 transfer when HTTP-style headers precede the data. When set to 172 zero, no HTTP-style headers precede the resource data. 174 CRC Follows (C) : 1 bit 176 When the CRCFollows bit is set to 1, a 32 bit CRC is calculated 177 and can be used used to detect possible corruption in the data 178 delivered via UHTTP. Using the MPEG-2 CRC algorithm, the CRC is 179 calculated on the complete data, including HTTP-style headers, if 180 any. It is then appended to the end of the data in the last 181 logical packet. This CRC field is considered part of the data for 182 the purposes of calculating the resource length and calculating 183 the forward error correction. The bit must be set in all packets 184 associated with a UHTTP transfer when a CRC is used. 186 Packets In XOR Block (PcktsInXORBlk) : 1 byte 188 Describes the number of packets in a forward error correction 189 block, including the forward error correction packet. Set to zero 190 when no forward error correction is used. See Section 4 for 191 details on the forward error correction mechanism. 193 Retransmit Expiration : 2 bytes 195 Time in seconds over which the resource may be retransmitted. 196 This indicates how long the receiving software should wait to try 197 to recover missing packets that follow in retransmissions of the 198 same resource. This allows a resource to be carouseled, or sent 199 repeatedly to increase the chances of delivery without missing 200 segments. The RetransmissionExpiration field should be updated 201 to remain accurate during retransmissions, including the current 202 transmission. 204 TransferID : 16 bytes 206 Globally unique identifier (UUID[1]) for the UHTTP transfer. This 207 ID allows receiving software to identify which segments 208 correspond to a given transfer, and determine when retransmission 209 occurs. 211 Resource Size : 4 bytes 213 Size of the complete resource data itself (excluding segment 214 headers, XOR segments and padding for exclusive-or correction). 216 This length does include the length of the HTTP-style headers, if 217 any, as well as the 4-byte CRC, if the CRCFollows bit is set to 1. 219 Segment Start Offset : 4 bytes 221 Start offset for the first byte in the transfer for this data 222 segment. When XOR data is used to replace missing packets, 223 SegStartByte includes the XOR data as well as the resource data, 224 and optional HTTP-style headers and CRC. This allows for 225 determining where all packets fit regardless of delivery order. 226 The exclusive-or correction packet looks like any other UHTTP 227 packet. Its data payload is simply the exclusive-or of a number 228 of packets that precede it in order in the data. The number of 229 packets in an XOR block is specified in the PacketsInXORBlock 230 field described above. 232 The UDP packet data length for the enclosing UDP packet is used to 233 determine the length of the segment. It is permissible to send a 234 packet that contains UHTTP header (and optional extension headers), 235 but without any data. If no data is included, then the SegStartByte 236 field is ignored. 238 3.2 UHTTP Extension Header Format 240 If the ExtensionHeader flag is set in a UHTTP packet header, 241 additional optional header fields are present. These fields appear 242 directly after main UHTTP header. Extension headers are optional on 243 a packet-by-packet basis, and may appear on none, some or all of the 244 UHTTP packets transmitted, depending on the ExtensionHeaderType. 245 This specification defines a single extension header type, 246 HTTPHeaderMap (defined below). Any extension headers with an unknown 247 type should be ignored by receivers. 249 When the Extension Header (H) is set to a value of one, one or more 250 extension headers may follow the UHTTP header and precede the data 251 segment in that packet. Extension headers have the following format: 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 |F| extension header type | extension header length | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | extension header data | 258 | .... | 260 ExtensionHeaderFollows (F) : 1 bit 262 When 1, this field indicates that another extension header 263 follows this one. When 0, the UHTTP data payload follows this 264 extension header. 266 ExtensionHeaderType : 15 bits 268 Identifies the extension header type. (1 = HTTPHeaderMap, all 269 other values reserved). 271 ExtensionHeaderDataSize : 2 bytes 273 Describes the length of the complete Extension Header data in 274 bytes. Zero indicates that there is no ExtensionHeaderData 275 following. 277 ExtensionHeaderData 279 The variable length data for this extension header. The length of 280 the ExtensionHeaderData field is indicated by the 281 ExtensionHeaderDataSize. 283 If the ExtensionHeaderFollows bit is set, then another 284 ExtensionHeader follows this header. If the bit is cleared, then the 285 UHTTP data payload follows the ExtensionHeaderData (if any) 286 immediately. 288 3.2.1 HTTPHeaderMap Extension Header 290 One ExtensionHeaderType is defined for this specification. When 291 ExtensionHeaderType is set to a value of 1, then the 292 ExtensionHeaderData field contains an HTTPHeaderMap. A HTTPHeaderMap 293 extension header may optionally be included whenever the UHTTP 294 transfer contains HTTP-style header information (as indicated by the 295 HTTPHeadersPrecede bit in the main UHTTP header). If HTTPHeaderMap 296 extension headers are used, they should be included in every packet 297 in a UHTTP transfer that contains header, body or forward error 298 correction (FEC) data. 300 The HTTPHeaderMap consists one or more sets of the following fields: 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | HTTP header start | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | HTTP header size | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | HTTP body size | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 HTTPHeaderStart : 4 bytes 313 This field indicates an offset into the UHTTP data, in bytes, 314 where a HTTP-style header is found. The offset is calculated from 315 the beginning of the corrected UHTTP data, and does not include 316 the FEC data when the FEC mechanism is used. 318 HTTPHeaderSize : 4 bytes 320 This field indicates the length of the HTTP-style header, in 321 bytes, including the HTTP-style header fields, the terminating 322 pair of carriage-return/newline character sequences, and any 323 preceding multipart boundary lines. 325 HTTPBodySize : 4 bytes 327 This field indicates the length of the data body, in bytes, 328 associated with the HTTP header described in this map entry. 330 When the UHTTP transfer consists of a single (i.e. non-multipart) 331 resource, a single 12 bytes set of HTTPHeaderMap fields is present 332 in the HTTPHeaderMap. The HTTPHeaderStart, in this case, will be set 333 to zero and the HTTPHeaderSize will be set to the sum of the length 334 of the HTTP-style header fields and all separating 335 carriage-return/newline characters. The HTTPBodySize field will 336 contain the size, in bytes, of the body data related to that header 337 field. 339 When a UHTTP transfer contains multiple resources (as specified by a 340 multipart content-type), multiple sets of HTTPHeaderMap groups may 341 be included in the HTTPHeaderMap data, each indicating the offset 342 and size of the HTTP-style headers for each resource, (including any 343 multipart boundary lines, HTTP-style header fields and separating 344 carriage-return/newline characters), as well as the size of the body 345 relating to each header. 347 When including HTTPHeaderMap data, senders must at a minimum include 348 HTTPHeaderMap entries for each HTTP-style header that is partially 349 or completely included in a given packet. Additionally, when forward 350 error correction is used in UHTTP transfers that contain 351 HTTPHeaderMaps extension headers, senders must include HTTPHeaderMap 352 entries as extension headers in FEC-data packets for all HTTP-style 353 header sections that may be corrected by the FEC packet. Senders are 354 free to include additional HTTPHeaderMap entries in any packet 355 beyond the minimum. 357 4. Forward Error Correction Mechanism 359 In addition to the ability to retransmit data and have missing 360 segments filled in during retransmissions, this transfer protocol 361 can also include extra data packets that can be used for simple 362 missing packet error correction. When the PacketsInXORBlock header 363 field is set to zero, there is no exclusive-or forward error 364 correction. When non-zero, forward error correction packets may be 365 sent to allow for correction of missing or corrupted packets by the 366 receiver. It is permissible to send packets with no data payload 367 (but with UHTTP headers and optional extension headers). In this 368 case, the packet is ignored in the calculation of forward error 369 correction. 371 In blocks of PacketsInXORBlock equal size data segments, the last 372 data segment in the block contains the exclusive-or of the preceding 373 segments (PacketsInXORBlock - 1). Each byte of the data in this "XOR 374 segment" is the exclusive-or of the corresponding byte in each of 375 the other segments in that data block. If the data is thought of as 376 laid out separated into consecutive segments, then after every 377 PacketsInXORBlock - 1 segments another segment is inserted that 378 looks exactly like resource data and has its own position offset 379 into the transfer like resource data. The data in that segment is 380 the exclusive-or of the previous packets in that block. Data in the 381 XOR segment is the exclusive-or of data segment contents only, 382 including the HTTP-style header fields but not including the UHTTP 383 header that is also in the packet. 385 If forward error correction is used, the data payload of all 386 packets must be the same size. The packet containing the data at the 387 end of the file (including the optional CRC) must be zero filled. 388 Packets between this packet and the last XOR packet need not be sent 389 since the receiver knows their contents are all zeros, as it was 390 provided the overall length in the UHTTP resource size field. If 391 they are sent they must be zero filled after the segment header; if 392 not sent, they are assumed to contain a payload of all zero bytes 393 for the purposes of forward error correction calculations. The last 394 XOR packet has the value SegStartByte calculated to be just as if 395 zero-filled extra packets were sent, but there is no requirement to 396 send those empty packets. 398 To correct for a single missing packet in a block, the receiver 399 should calculate the exclusive-or the data payload of the packets 400 that arrived with the XOR data segment for that block. An important 401 point is that segments can be sent in any order since each segment 402 including the XOR segment indicate where in order they belong. By 403 sending segments (including the XOR packets) out of order, there may 404 be protection against burst errors that lose successive packets. 405 When re-transmitting a UHTTP transfer, a different order of segments 406 can be used in each retransmission to avoid different types of burst 407 errors. This protocol allows the headend (broadcast side) tools to 408 decide how to order sending packets, thereby providing a great deal 409 of flexibility. The receiving side does not need to know the 410 transmission order (consistent with the fact that in general it 411 cannot know the transmission order for IP multicast delivery). 413 5. HTTP-style headers used in UHTTP 415 The UHTTP transfer protocol can be used to deliver resources via a 416 broadcast medium, which can simultaneously deliver resources, 417 including web-related content, to large numbers of users 418 simultaneously. HTTP-style header fields can be included in the 419 UHTTP data to provide meta-information about the content, including 420 identifying URIs, expiration dates and content type and encoding. 421 The use of HTTP-style headers is optional in UHTTP, but is required 422 for resources intended to be interpreted as web content. 424 HTTP-style headers, as specified by HTTP 1.1[5], precede the 425 resource content just as in HTTP transfers when resources are sent 426 as a response to a HTTP GET or POST command. The HTTP-style headers 427 may provide additional information to the browser, for example, the 428 expiration time for the resource. The HTTP-style headers precede the 429 body of the resource data, and are treated as part of the data 430 payload. The protocol header and its version imply the equivalent 431 HTTP response line (e.g. "HTTP/1.1 200 OK"). Relevant header fields 432 are listed below and should be interpreted per the HTTP 1.1[5] 433 specification. 435 5.1 Supported HTTP-style headers 437 Header fields required for every resource when using HTTP-sytle 438 headers: 440 Content-Length: 441 Content-Location: 443 Recommended HTTP-style header fields: 445 Content-Type: 447 Optional HTTP-style header fields: 449 Content-Base: 450 Content-Encoding: 451 Content-Language: 452 Content-Style-Type: 453 Date: 454 Expires: 455 Last-Modified: 457 UHTTP transfers that utilize HTTP-style headers MUST contain the 458 required headers listed above ("Content-location" and 459 "Content-length"), to ensure that an appropriate URI is specified 460 for the resource and to ensure that the resource data is delivered 461 in whole. No other header fields are strictly required, but may 462 provide useful information to the receiver in determining the 463 disposition of the content. 465 Receivers will decode the headers and data and store them in a local 466 cache system. Different receiver platforms will have different cache 467 sizes for storing local resources, which may or may not correspond 468 to traditional web browser caches. Resources transmitted with 469 "Content-location" header fields which contain "http:" URLs identify 470 resources which are also available via an HTTP request specified by 471 that URL. The use of "Content-Location:" headers with local 472 identifier[3], or "lid:" URLs is intended to mirror resource 473 delivery to a local cache without requiring that the data be 474 available on the Internet. 476 Receiving platforms should take into consideration that the same 477 resources will likely be sent repeatedly to provide resources for 478 users who tune in late. HTTP-style header fields can be examined to 479 determine if the resource is already present, and so can be ignored. 480 The "Date:", "Expires:", and "Last-Modified:" headers can be used to 481 determine the lifetime of a resource in a given receiver's cache. 483 6. Packaging more than one resource 485 It is possible to send multiple resources in a single UHTTP transfer 486 by packaging them into a single multipart resource for 487 all-or-nothing transfer. In this case, the HTTP-style 488 "Content-Type:" header field would have a value of 489 "multipart/related"[2]. When this type is used, the HTTP-style 490 header is ended as usual and is followed by the usual boundary 491 structure for "multipart/related" separating multiple related 492 resources that each use the HTTP-style header formats. This is a 493 mechanism to package multiple related resources together in a single 494 all-or-nothing transfer. The HTTP-style headers for individual 495 sub-parts describe only that sub-part, and are interpreted as per 496 the HTTP 1.1 specification[5]. In this case, it may be convenient to 497 specify a "Content-Base:" for the entire package and then specify 498 relative URLs for each of the "Content-Location:" headers for 499 subsequent subparts. 501 The "multipart/related" content type should be used as per RFC 502 2387[2]. 504 An example using HTTP scheme URLs: 506 Content-Base: http://www.blahblah.com/ 507 Content-Length: 3495 508 Content-Type: Multipart/Related; boundary=example98203804805 509 --example98203804805 510 Content-Location: resource1.html 511 Content-Length: 495 512 Content-Type: text/html 514 ...Resource data for resource1.html... 515 ...... 516 --example98203804805 517 Content-Location: image1.jpg 518 Content-Length: 1495 519 Content-Type: image/jpeg 521 ...Resource data for image1.jpg... 522 --example98203804805 523 A similar example using "lid:" style URLs and relative URLs: 525 Content-Base: lid://unique2345@blahblah.com/ 526 Content-Length: 3495 527 Content-Type: Multipart/Related; boundary=example98203804805 528 --example98203804805 529 Content-Location: resource1.html 530 Content-Length: 495 531 Content-Type: text/html 533 ...Resource data for resource1.html... 534 ...... 535 --example98203804805 536 Content-Location: image.jpg 537 Content-Length: 1495 538 Content-Type: image/jpeg 540 ...Resource data for image1.jpg... 541 --example98203804805 543 7. Security Considerations 545 There are a number of security issues associated with the use of 546 UHTTP to deliver content on public broadcast networks, many of which 547 are shared with electronic mail systems. When HTTP-style headers 548 are used to identify the resources in a UHTTP transfer, it is 549 possible for the sender to misrepresent the content with URIs which 550 do not match the transmitted content. The security issues 551 associated with this mislabeling, as well as the security issues 552 associated with the use of HTML content which is broadcast are the 553 same as those identified in section 11.1 of RFC 2387[2]. 554 Additionally, there are security issues associated with the caching 555 of data transmitted via UHTTP which are the same as those identified 556 in section 11.2 of RFC 2387[2]. 558 It should be noted that many broadcast systems employ conditional 559 access systems (satellite and cable television, for example) which 560 provides a level of security for the broadcast channel leading up to 561 the receiver. Unfortunately, it may be possible to insert UHTTP 562 data earlier in the broadcast chain at points which are less secure 563 (on videotape to be played into the system, for example), so 564 applications using UHTTP may which cannot ensure end-to-end security 565 of the broadcast system should employ additional security 566 mechanisms. 568 References 570 [1] Leach, P. J. and R. Salz, "UUIDs and GUIDs", Internet Draft 571 draft-leach-uuids-guids-01, February 1998. 573 [2] Levinson, E., "The MIME Multipart/Related Content-type", RFC 574 2387, August 1998. 576 [3] Blackketter, D., "The Local Identifier URL Scheme", Internet 577 Draft draft-blackketter-lid-00, August 1999. 579 [4] Technical committee / subcommittee: JTC 1 / SC 29, "ISO/IEC 580 13818-1:1996, GENERIC CODING OF MOVING PICTURES AND ASSOCIATED 581 AUDIO INFORMATION - PART 1: SYSTEMS, Annex A: CRC Decoder 582 Model", ISO/IEC 13818-1:1996, January 1996. 584 [5] Fielding, R., "Hypertext Transfer Protocol -- HTTP/1.1", RFC 585 2068, January 1997. 587 [6] ATVEF, "Advanced Television Enhancement Forum Specification, 588 draft 1.1r26", February 1999. 590 Author's Address 592 Dean J. Blackketter 593 WebTV Networks, Inc. 594 1295 Charleston Road 595 Mountain View, CA 94043 596 US 598 Phone: +1 650 614 5521 599 EMail: dean@corp.webtv.net 600 URI: http://www.webtv.net/ 602 Appendix A. Acknowledgements 604 The author gratefully acknowledges the contributions of the ATVEF 605 Technical Working Group, and in particular: Lee Acton, Jonathan 606 Boltax, Wayne Carr, Michael Dolan, CJ Frederickson, Iain Hackett, 607 Cheryl Kadis, David Mott, Scott Watson, Mark Vickers, and Dan 608 Zigmond.