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.