idnits 2.17.00 (12 Aug 2021) /tmp/idnits23607/draft-rey-avt-3gpp-timed-text-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 433 has weird spacing: '...gs. If the p...' == Line 1059 has weird spacing: '...for the purpo...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: - SIDX (8 bits) "Text Sample Entry Index": indicates the reference index for the text sample, which corresponds to the index field in the Sample to Chunk Box, "stsc", for the sample. This field is used to map the corresponding sample description information. The SIDX is unequivocally linked to one particular sample description. Therefore, sample descriptions SHALL not be modified during a streaming session. A maximum of 126 SIDX values is allowed per text stream. To allow SIDX wrap-up, clients SHALL keep as valid only those values of SIDX outside of the interval (X+128) modulo 255, where X is the last SIDX value received. The SIDX values 0 (0x00) and 255 (0xff) are reserved for possible future extensions. -- 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 2004) is 6669 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) -- Missing reference section? '1' on line 998 looks like a reference -- Missing reference section? '2' on line 964 looks like a reference -- Missing reference section? '9' on line 966 looks like a reference -- Missing reference section? '4' on line 811 looks like a reference -- Missing reference section? '13' on line 346 looks like a reference -- Missing reference section? '8' on line 187 looks like a reference -- Missing reference section? '5' on line 210 looks like a reference -- Missing reference section? '3' on line 861 looks like a reference -- Missing reference section? '14' on line 310 looks like a reference -- Missing reference section? '15' on line 441 looks like a reference -- Missing reference section? '11' on line 678 looks like a reference -- Missing reference section? '10' on line 867 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft 3 draft-rey-avt-3gpp-timed-text-02.txt J. Rey 4 Y. Matsui 5 Matsushita 7 Expires: August 2004 February 2004 9 RTP Payload Format for 3GPP Timed Text 11 Status of this document 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC 2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 This document specifies an RTP payload format for the transmission of 38 3GPP (3rd Generation Partnership Project) timed text. 3GPP timed 39 text is time-lined decorated text media format whose defined storage 40 format is the ISO (International Standardisation Organisation) Base 41 Media File Format. As of today, 3GP files containing timed text 42 contents can be downloaded via HTTP and be synchronised with 43 audio/video contents. There is however no available mechanism for 44 streaming 3GPP timed text contents. In the following sections the 45 problems of streaming timed text are addressed and a payload format 46 for streaming 3GPP timed text over RTP is specified. 48 Table of Contents 50 1. Change Log......................................................2 51 2. Introduction....................................................3 52 3. Terminology.....................................................5 53 4. RTP Payload Format for 3GPP Timed Text..........................5 54 5. Resilient Transport............................................13 55 6. Congestion control.............................................13 56 7. SMIL usage.....................................................14 57 8. MIME Type usage Registration...................................14 58 9. SDP usage......................................................16 59 10. Examples of RTP packet structure..............................17 60 11. IANA Considerations...........................................17 61 12. Security considerations.......................................17 62 13. References....................................................18 63 14. Annex A Basics of 3GP File Structure..........................19 64 15. Author's Addresses............................................20 65 16. IPR Notices...................................................21 66 17. Full Copyright Statement......................................21 68 1. Change Log 70 1.1 Changes from draft-rey-rtp-avt-3gpp-tt-00.txt 72 Major changes: 73 - completed empty sections from -00 draft. 74 - abstract and introduction re-arranged. Moved section "Basics of the 75 3GP File Structure" to end of the document as Annex B. 76 - SLEN, SIDX and SDUR lengths fixed to 16, 16 and 24 bits, 77 respectively. 78 - New OPTIONAL header, SPLDESC, added to transport sample description 79 in-band. 80 - Section 4 on payload format expanded: text header, fragment header 81 and sample description header are fully specified. 82 - SMIL usage section added. 84 1.2 Changes from draft-rey-rtp-avt-3gpp-tt-01.txt 86 Major changes: 88 - Terminology, some terms introduced to clarify text. 89 - Section 4 90 - rules and recommendations on fragmentation are given. 91 - payload headers were calssified into five types, with a common 92 field section and specific fields for each type. 94 - header structure similar to RFC 3640 for easy transformation. 96 2. Introduction 98 The purpose of this draft is to provide a means to stream the 3GPP 99 timed text using RTP. 101 3GPP timed text is a 3GP file format for time-lined decorated text 102 specified in [1]. The 3GP file format itself follows the ISO Base 103 Media File Format recommendation [2]. Besides plain text, the 3GPP 104 timed text format allows the display of decorated text (e.g. blinking 105 text, scrolling, hyperlinks) synchronised or not with other media. 107 The 3GPP timed text format was developed for 3GPP Transparent End-to- 108 end Packet-switched Streaming Services (PSS) [1]. The scope of the 109 3GPP PSS includes downloading and streaming of multimedia content 110 over 3G packet-switched networks. The PSS adopts multimedia codecs 111 (such as MPEG-4 Visual, AMR, MPEG-4 AAC, and JPEG) and protocols like 112 SMIL [9] for presentation layouts or RTP for streaming. The current 113 usage of the 3GPP timed text file format is limited to downloading 114 via HTTP (with or without audio contents) due to the lack of an 115 appropriate RTP payload format. 117 In general, a multimedia presentation might consist of several 118 audio/video/text streams or tracks (in 3GP file format jargon). 119 Different tracks may have different contents and tracks of different 120 media may be spatially synchronised using the information within the 121 tracks or a scene description language like SMIL. An example of this 122 would be a media session with three different media tracks: 1 audio, 123 1 video and 1 timed text that reproduces a music video with karaoke 124 subtitles. The information contained in each track defines the 125 regions where each media is displayed, how the media looks like and 126 how it is synchronised, e.g., the song lyrics is displayed below the 127 video and the words are highlighted and synchronised with the 128 soundtrack. 130 Basically the 3GPP timed text format can be summarised as consisting 131 of four differentiated functional components: 133 - initial setup information for text tracks: these are the height 134 and width of the text region where the text track (contents) are 135 displayed, the translation offsets tx and ty relative to the video 136 track region and the layer or proximity of the text to the user. In 137 the 3GPP timed text format, these pieces of information are extracted 138 from Track Header Box, "tkhd". 139 - general formatting information about the text track: default font, 140 default background colour, default horizontal and vertical 141 justification, default line width, default scrolling, etcetera. In 142 the 3GPP timed text format, these pieces of information are extracted 143 from the Sample Description Box, "stsd". 144 - the actual text, conveyed as plain text using either UTF-8 or UTF- 145 16 encoding and, 146 - the "decoration": whether it is highlighted text, blinking text, 147 karaoke, hypertext, scroll delay, other text styles/formatting than 148 the defaults, etcetera. In the 3GPP timed text format, these pieces 149 of information are extracted from the various Modifier Boxes: "hlit", 150 "hclr", "blnk", "krok", "href", "dlay", "styl" or "tbox". 152 For details refer to Annex A that summarises the basics of the 3GP 153 file format and to [1], where a more detailed description of the 154 setup information, format parameters and modifiers is contained. 156 2.1 Requirements 158 In this section a set of requirements is listed. A justification for 159 each of them is also given. An RTP Payload Format for 3GPP timed 160 text SHALL: 162 1. Keep the 3GP text sample structure. A text sample consists 163 of the text length, the text string (either UTF-8 or UTF-16 encoded), 164 and one or several Modifier Boxes containing the text "decoration", 165 as defined in [1]. This is important to foster interoperability of 166 3GP file and RTP payload formats. 168 2. Transmit the text sample size, sample duration and sample 169 description index in-band. In RTP it is important to transmit it in- 170 band because this information might change from sample to sample. 171 This is also important for buffering purposes as described in Section 172 4.1. 174 3. Enable the transmission of the formatting information 175 (contained in the Sample Description Box, "stsd") by out-of-band and 176 in-band means. In general, a single sample description may be used 177 by different text samples. Therefore, to save overhead it is 178 sensible to transmit a default formatting once at the initialisation 179 phase and update this on demand. On the other hand, these pieces of 180 information may become large so that out-of-band transmission might 181 not be the most appropriate method. Also, out-of-band channels might 182 not be always available. For these reasons, the payload format SHALL 183 enable also the in-band transmission of sample description 184 information. This is especially useful for live streaming (where the 185 contents are not known a priori) or to protect this information 186 through other mechanisms like FEC [4] or retransmission [13]. RFC 187 2354 [8] discusses available mechanisms for packet loss resiliency. 189 4. Enable the aggregation of text samples in one single RTP 190 packet. In a mobile communication environment a typical text sample 191 size is around 100-200 bytes. Thus, transporting several text 192 samples in one RTP packet makes the transport over RTP more 193 efficient. 195 5. Enable the fragmentation and reassembly of a text sample 196 into several RTP packets in order to cover a wide range of 197 applications and network environments. In general, fragmentation is 198 a rare event given the low bit rates and text sample sizes. However, 199 the 3GPP Timed Text media format allows for larger text samples and 200 so SHALL the payload format cover this possibility. 202 6. Enable the use of resilient transport mechanisms, such as 203 repetition, retransmissions and FEC. 205 3. Terminology 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 209 document are to be interpreted as described in RFC 2119 [5]. 211 Furthermore, the following definitions are used in this document: 213 - text sample or whole text sample: this refers to a unit of text 214 data as contained in the source 3GP file. Its equivalent in 215 audio/video would be an audio/video frame (see Section 14 for 216 details). A text sample contains a text length indication, a text 217 string, and zero or several modifier boxes (the decoration of the 218 text). 219 - fragment or text sample fragment: a fraction of a text sample as 220 defined above. A fragment may either text strings and modifiers or 221 just one of these. 222 - sample contents: general term to identify timed text data 223 transported when using this payload format. In addition to text 224 samples and fragments, it may also be used to refer to the sample 225 descriptions associated to the text samples. 227 4. RTP Payload Format for 3GPP Timed Text 229 The format of an RTP packet containing 3GPP timed text is shown 230 below: 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 |V=2|P|X| CC |M| PT | sequence number | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | timestamp | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | synchronization source (SSRC) identifier | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | | 242 + RTP payload | 243 | | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 Marker bit (M): the marker bit must be set to 1 if the RTP packet 247 includes the last fragment of a text sample; otherwise set to 0. For 248 RTP packets containing several text samples, being at least one of 249 them non-fragmented, the marker bit MUST be set to 1. 251 Timestamp: the timestamp indicates the sampling instant of the timed 252 text sample contained in the RTP packet. The initial value is 253 randomly determined. If the RTP packet includes more than one text 254 sample (i.e. text sample aggregation), the timestamp indicates the 255 sampling instant of the oldest text sample in the RTP packet. The 256 samples MUST be placed in playout order, whereas the oldest sample is 257 placed first in the payload. The timestamp of the subsequent samples 258 is obtained by adding the timed text sample duration (if present) to 259 the timestamp value. For example, let sdur(0), sdur(1) and sdur(2) 260 be the durations of three subsequent timed text samples included in 261 an RTP packet. Let rtpts be the timestamp as present in the RTP 262 header. The timestamp ts(i) for each sample (i=0,1,2) would be: 264 ts(i)=rtpts + sum[sdur (i-1)]; 266 ts(0)=rtpts, 267 ts(1)=rtpts + sdur(0) 268 ts(2)=rtpts + (sdur(0)+ sdur(1)) 270 Some text samples may become large and have to be fragmented and so 271 spread over several RTP packets. In this case, the receiver needs to 272 associate fragments of the same text sample. This is done using the 273 timestamp. The order of the fragments is resolved using the fields 274 available in the following headers. 276 The value timestamp clockrate is copied directly from the 3GP file: 277 the value of "timescale" in the Media Header Box is to be used. 279 Payload Type (PT): the payload type is set dynamically and sent by 280 out-of-band means. 282 The usage of the remaining RTP header fields follows the rules of RTP 283 [3] and the profile in use. 285 4.1 Fragmentation of Timed Text Samples 287 This section justifies why text samples MAY be fragmented and 288 discusses some of the possible approaches to do it. A solution is 289 proposed together with rules and recommendations for fragmenting and 290 transporting text samples using this payload format. 292 3GPP Timed Text applications are expected to operate at low bit rates. 293 This fact added to the small size of timed text samples (typically 294 one or two hundred bytes) makes fragmentation of text samples a rare 295 event. Samples should usually fit into the MTU size of the used 296 network path. 298 Nevertheless, the text string (e.g. ending roll in a movie) and some 299 modifier boxes, i.e. for hyperlinks ("href"), for karaoke ("krok") or 300 for fonts ("styl") might become large and need fragmentation. This 301 may also apply for future modifier boxes. While the text string is 302 recommended as per [1] to take a maximum of 2048 bytes for maximum 303 client interoperability, there is no recommendation on the amount of 304 space occupied by modifier boxes. 306 In order to transport these larger text samples using RTP, it could 307 be argued that a careful encoding be used to transform the original 308 large sample into smaller self-contained text samples that fit into 309 the transport MTU. This would comply with the ALF principle, as per 310 RFC 2367 [14]. It would also need additional pre-processing previous 311 to RTP encapsulation. Given the low probability of fragmentation, it 312 is believed that the overhead of this pre-processing (careful 313 encoding) is not worth. It appears more appropriate to encode text 314 samples without taking the path MTU into account. In this manner, 315 this payload format meets a trade-off by intentionally leaving out 316 this pre-processing and making some text samples more sensitive to 317 packet losses. 319 However, a minimum set of fragmentation rules and recommendations 320 SHALL be observed to guarantee a minimum resiliency and guide in the 321 task of fragmentation. Text samples and fragments thereof are 322 aggregated in the RTP payload according to the rules and 323 recommendations specified as follows: 325 - it is RECOMMENDED that text samples are fragmented as seldom as 326 possible. E.g. if a previous packet has some free space and a new 327 text sample fits in one MTU, a new RTP packet SHOULD be sent, instead 328 of sending two or more fragments out of it. In order to fill up the 329 remaining bits, piggybacking of sample descriptions MAY be performed. 331 - text strings MUST split at character boundaries. Otherwise, it is 332 not possible to display the text of a fragment if the previous is 333 lost. 335 - it is RECOMMENDED to include as fewer text sample fragments as 336 possible in an RTP packet. This reduces the effects of packet loss. 337 RTP packets using this payload format MAY include zero or more whole 338 text samples, zero or more text sample fragments and zero or more 339 sample descriptions. 341 - sample descriptions SHALL NOT be fragmented, since they contain 342 important information that may affect several text samples. 344 - for enhanced resiliency against packet loss it is RECOMMENDED that 345 fragments containing decoration are especially protected using FEC 346 [4], retransmission [13], packet repetition or a similar technique. 348 - when fragmenting text samples, the start of the decoration 349 (modifiers) MUST be indicated. Otherwise, if packets are lost, a 350 client may be unable to identify where the modifiers start and the 351 text ends. 353 Usually, RTP applications use the information on packet size from UDP 354 or lower layers to find out the length of the RTP payload. This 355 means that if several text samples (or fragments) are contained in 356 the payload a length indication MUST be present for all fragments, 357 but the last one. Similarly, those transported as unique payload do 358 not need of a length indication. 360 However, some transport schemes for RTP, e.g. RFC 3640 [15], require 361 that the length of each fragment is indicated. This payload format 362 does not mandate to comply with such requirement, but OPTIONALLY 363 allows to do so. Implementations subject to such requirement MUST 364 include an explicit length indication,i.e. the LEN field, by setting 365 the L bit in all cases. 367 Note also that the order of the text samples and fragments in the RTP 368 payload is important. As described above in the definition of the 369 RTP timestamp usage, these MUST be placed chronologically in the RTP 370 payload, so that the SDUR field allows calculating the timestamp of 371 the samples following. At the same time, other samples MAY follow if 372 the current and following samples contain each a length indication. 373 Otherwise, the sample is either placed at the end or as unique RTP 374 payload. Fragments carrying modifier box contents and sample 375 descriptions MAY be placed in any order (no timing requirements) and 376 MAY be present as often as needed. Modifier box fragments SHOULD be 377 placed as close as possible to the text strings, which they belong 378 to. 380 4.2 Payload Header Definitions 382 An RTP packet using the payload headers defined in this document has 383 the following format: 385 0 1 2 3 386 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 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 |V=2|P|X| CC |M| PT | sequence number | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | timestamp | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | synchronization source (SSRC) identifier | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Res.|U|L|TYPE | | 395 +-+-+-+-+-+-+-+-+ | 396 : (variable payload header depending on TYPE value) : 397 : : 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | | 400 : SAMPLE CONTENTS = Text Sample(s), Fragment(s), Sample : 401 : Description(s) : 402 : : 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 The payload headers specified in this document consist of a set of 406 common fields followed by specific fields for each header type. 408 The structure of the payload headers resembles that of the 'access 409 units' in RFC 3640. This similarity is intentional, in order to ease 410 the transport using MPEG4 elementary streams. In this manner, the 411 'AU header' of that document finds an equivalent in the common header 412 fields for all TYPE values: R, U, L, TYPE and LEN. The specific 413 fields plus the sample contents would be similar to the 'AU data 414 section'. 416 The payload header the following format: 418 0 1 2 3 419 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 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | R |U|L|TYPE | LEN (if L=1) | specific | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | fields (variable)...| 424 +-+-+-+-+-+-+-+-+-+-+-+-+ 426 where, 428 - R (3 bits) "Reserved bits": this field MUST be set to zero. 430 - U (1 bit) "UTF Transformation": indicates whether the text 431 characters are encoded using UTF-8 (U=0) or UTF-16 (U=1). It MUST 432 also be present in text sample fragments if they contain text 433 strings. If the payload does not carry text strings, this bit has 434 no meaning and SHALL be disregarded. 436 - L (1 bit) "Length Field" flag: if set indicates the presence of the 437 OPTIONAL length field, LEN. By default this flag is reset. Where 438 several 'access units' are included in an RTP packet, the length MUST 439 be used to parse the payload. In this case, it SHALL be present in 440 all 'access units' but the last one. In some cases, as in RFC 3640 441 [15], the length field is always needed, and so MUST L flag be always 442 set. 444 - LEN (16 bits) "Length Field": indicates the size (in bytes) of this 445 field and all the bits following, i.e. specific payload header fields 446 for each TYPE (excluding initial byte) plus the sample contents. If 447 present, LEN has the following values: 449 - TYPE = 1, LEN >= 6, 450 - TYPE = 2, LEN > 9, 451 - TYPE = 3, LEN > 3, 452 - TYPE = 4, LEN > 3, 453 - TYPE = 5, LEN > 3. 455 For whole text samples (TYPE=1), the sample contents length 456 corresponds to the entry value in the Sample Size Box, "stsz" (see 457 also SLEN below). Otherwise the sample contents length MUST be 458 calculated when fragmenting the sample, in order to obtain the 459 correct LEN value. 461 Empty text samples do not have sample contents. For this case, TYPE 1 462 with a LEN of 6 (0x0006) MUST be used. 464 The following payload header compositions (including the specific 465 fields) result for the different values of TYPE: 467 - TYPE = 0,6 and 7 are reserved. 468 - TYPE = 1, 470 0 1 2 3 471 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 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | R |U|L|TYPE | LEN (if L=1, always >=6)| SIDX | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | SDUR | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 This header type is used to transport whole text samples. If several 479 text samples are sent in an RTP packet, every sample has its own 480 header. 482 The LEN field MUST be always equal (for empty text samples) or 483 greater than 6 (0x0006). 485 The fields above have the following meaning: 487 - SIDX (8 bits) "Text Sample Entry Index": indicates the reference 488 index for the text sample, which corresponds to the index field in 489 the Sample to Chunk Box, "stsc", for the sample. This field is used 490 to map the corresponding sample description information. The SIDX is 491 unequivocally linked to one particular sample description. 492 Therefore, sample descriptions SHALL not be modified during a 493 streaming session. A maximum of 126 SIDX values is allowed per text 494 stream. To allow SIDX wrap-up, clients SHALL keep as valid only 495 those values of SIDX outside of the interval (X+128) modulo 255, 496 where X is the last SIDX value received. The SIDX values 0 (0x00) 497 and 255 (0xff) are reserved for possible future extensions. 499 - SDUR (24 bits) "Text Sample Duration": indicates the sample 500 duration in timestamp units of the text sample, which corresponds to 501 the entry value in the Decoding Time to Sample Box, "stts", for that 502 sample. This field allows by a clockrate of 1000 Hz a maximum 503 duration of approximately 279 hours (16 bits is would allow for just 504 65 seconds, which might be too short for some streams). 506 It is assumed that all text samples have a known duration at the time 507 of transmission. In some cases however, e.g. live streaming, the 508 SDUR value might not be known. To cover this exception, the value 509 zero (0x000000) is reserved to signal unknown duration. For all 510 other cases SDUR MUST be different from 0x000000. 512 The ordering of 'access units' in the RTP payload is important. 513 Logically, samples of unknown duration SHALL NOT precede any text 514 samples or text sample fragments in the RTP payload. Otherwise it 515 would not be possible to find out the timestamp of these. However, 516 samples of unknown duration MAY precede sample descriptions, as they 517 have no duration. 519 In general, text sample contents expire when the next sample becomes 520 valid. As an exception, samples of unknown duration (SDUR=0x000000) 521 are valid until new packets arrive. 523 Note also, that samples of unknown duration SHALL NOT use features, 524 such as scrolling or karaoke, which would need to know the duration 525 of the sample up-front. 527 - TYPE = 2, 529 0 1 2 3 530 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 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | R |U|L|TYPE | LEN(if L=1, always >9) | SIDX | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | SLEN | SDUR | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | SDUR (cont.) |TOTAL | THIS | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 This header type is used to transport text sample fragments 540 containing text strings. 542 The LEN field (16 bits) has the same meaning as above. If present, 543 the length of LEN MUST be greater than a value of nine (0x0009). 545 The SLEN field (16 bits) indicates the size (in bytes) of the (whole) 546 text sample to which this fragment belongs. As seen above, the text 547 sample length corresponds to the entry value in the Sample Size Box, 548 "stsz". Clients MAY use SLEN to buffer space for the remaining 549 fragments of the text sample. 551 The fields TOTAL (4 bits) and THIS (4 bits) indicate the total number 552 of fragments in which the original text sample has been fragmented 553 and which order occupies the current fragment in that sequence, 554 respectively. The usual 'byte offset' field is not used here for two 555 reasons: a) it would take one more byte and b) it does not provide 556 any useful information on the character offset. UTF-8/16 text 557 strings have, in general, a variable character length ranging from 1 558 to 6 bytes. Therefore, the TOTAL/THIS solution is preferred. 560 The R, U, L, TYPE, SIDX, and SDUR fields have identical 561 interpretation as above. The U, SIDX and SDUR fields are useful 562 since partial text strings MAY also be displayed with the 563 corresponding decoration. 565 - TYPE = 3, 567 0 1 2 3 568 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 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | R |U|L|TYPE | LEN(if L=1, always >3) |TOTAL | THIS | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 This header type is used to transport either whole modifier boxes or 574 just the first fragment of these. This depends on whether the 575 modifier boxes fit into one RTP packet. 577 In case fragmentation is needed, this header type identifies first 578 fragment. As explained above, the rules for fragmentation require 579 that the start of the modifier boxes be signaled. 581 The R, U, L, TOTAL/THIS and LEN fields are used as above. If present, 582 the LEN field MUST be greater than three (0x0003). 584 Note that the SLEN, SIDX and SDUR fields are not present. This is 585 because: a) these fragments do not contain text strings and b) these 586 types of fragments are applied over text string fragments, which 587 already contain this information. 589 - TYPE = 4, 591 0 1 2 3 592 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 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | R |U|L|TYPE | LEN(if L=1, always >3) |TOTAL | THIS | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 This header type is used to transport modifier fragments, other than 598 the first one. 600 The R, U, L, TOTAL/THIS and LEN fields are used as above. If present, 601 the LEN field MUST be greater than three (0x0003). 603 Note that the SLEN, SIDX and SDUR fields are not present. This is 604 because: a) these fragments do not contain text strings and b) these 605 types of fragments are applied over text string fragments, which 606 already contain this information. 608 - TYPE = 5 610 0 1 2 3 611 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 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | R |U|L|TYPE | LEN(if L=1, always >3) | SIDX | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 This header type is used to transport sample descriptions. The L 617 flag MUST be always set. Consequently, the LEN field MUST be greater 618 than three (0x0003). Every sample description MUST have its own TYPE 619 5 header. 621 5. Resilient Transport 623 Apart from the basic fragmentation measures described in the section 624 above, the simplest option for packet loss resilient transport is to 625 send the same text samples (or fragments) again, i.e. repetition. A 626 server MAY decide to send the same contents again as a measure for 627 error resilience. 629 Repetition of text samples (or fragments) is only allowed if exactly 630 the same RTP payloads are sent, so that a receiver can use original 631 and repeated fragments together to reconstruct the text samples. If 632 a text sample was originally sent as non-fragmented text sample, a 633 repetition of that sample MUST be sent also as a single non- 634 fragmented text sample. Likewise, if the original text sample was 635 fragmented and spread over several RTP packets, repeated fragments 636 SHALL also be observe the same byte boundaries and use the same 637 headers and bytes per fragment. Finally, if several text samples 638 resolve to the same timestamp, the receiver SHOULD use the one 639 received in the RTP packet with the highest sequence number and 640 discard the rest. 642 In repeated text samples (or fragments), all RTP header fields MUST 643 keep their original values except the sequence number that MUST be 644 increased to comply with RTP. 646 6. Congestion control 648 The RTP profile under which this payload format is used defines an 649 appropriate congestion control mechanism in different environments. 650 Following the rules under the profile, an RTP application can 651 determine its acceptable bitrate and packet rate in order to be fair 652 to other TCP or RTP flows. 654 If an RTP application using this payload format uses retransmission, 655 the acceptable packet rate and bitrate includes both the original and 656 retransmitted data. This guarantees that an application using 657 retransmission achieves the same fairness as one that does not. Such 658 a rule may translate in practice into the following actions: 660 If enhanced service is used, it should be made sure that the total 661 bitrate and packet rate do not exceed that of the requested service. 662 It should be further monitored that the requested services are 663 actually delivered. In a best-effort environment, the sender SHOULD 664 NOT send retransmission packets without ensuring first that enough 665 bandwidth for retransmission is available. Other solutions like 666 reducing the packet rate and bitrate of the original stream (for 667 example by encoding the data at a lower rate) MAY be used. 669 Similar considerations apply, if an RTP application using this 670 payload format implements forward error correction, FEC [4]. Hereby, 671 the sender should take care that the amount of FEC does not actually 672 worsen the problem. 674 Therefore, it is RECOMMENDED that applications implementing this 675 payload format also implement congestion control. The actual 676 mechanism for congestion control is out of the scope of this document 677 but should be suitable for real-time flows. As an example, RFC 3448 678 [11] specifies an equation-based congestion control that fulfils this 679 requirement. 681 7. SMIL usage 683 The SMIL recommendation [9] specifies a means for synchronising 684 different media streams. 686 This payload format defines the spatial layout parameters for a timed 687 text stream. These specify the location of the text display area 688 relative to the top left corner of the video display area, when a 689 text stream is played with a single video stream without SMIL. In 690 cases where several media streams shall be synchronized, SMIL MAY be 691 used to specify the spatial layout parameters. 693 It shall be noted that even if SMIL scene description is used the 694 track header information pieces SHOULD be sent anyway as they 695 represent the intrinsic media properties. 697 8. MIME Type usage Registration 699 8.1 3GPP Timed Text MIME Registration 701 MIME type: video 703 MIME subtype: 3gpp-tt 705 Required parameters: 707 rate: the RTP timestamp clockrate is equal to the clockrate of 708 the media. The value timestamp clockrate is copied directly 709 from the 3GP file: the value of "timescale" in the Media Header 710 Box is to be used. 712 brand=, where identifies a Release 713 specification of 3GPP Timed Text being transmitted over RTP. A 714 brand indicates the "best use" of the contents: the brand value 715 "3gp5" indicates Release 5 of 3GPP Technical Specification (TS) 716 26.245 [1]. 718 spldesc=, where may take three different values: 720 - spldesc=in, for in-band transmission of sample descriptions 721 - spldesc=out, for out-of-band and, 722 - spldesc=both, when both methods are allowed. 724 tx3g=, ,... where represents a list of sample description entries using base64 726 encoding. This parameter MAY be used to convey sample 727 descriptions out-of-band. The list of sample entries is not 728 required to follow any particular order. Each value represents the concatenation of the SIDX and sample 730 descriptions contents for that SIDX. The LEN field is not 731 needed. 733 width= indicates the width in pixels of the text 734 track or area where the text is actually displayed. 736 height= indicates the height in pixels of the 737 text track. 739 tx=, indicates the horizontal translation offset 740 in pixels of the text track with respect to the origin of the 741 video track. 743 ty=, indicates the vertical translation offset in 744 pixels of the text track. 746 layer=, indicates the proximity of the text track 747 to the viewer. Higher values means closer to the viewer. This 748 parameter has no units. 750 Optional parameters: 752 mver=, "Minor version" where is a 753 positive integer. It identifies the oldest compatible version. 754 How the version is defined can be found in TS 26.245 "3GPP 755 Transparent end-to-end packet switched streaming service (PSS); 756 Timed Text Format (Release 6)". 758 cbrand=, "List of Compatible Brands" where 759 value1 is a brand. This list MUST at least contain the as in "brand". 762 Encoding considerations: this type is only defined for transfer via 763 RTP. 765 Security considerations: please refer to Section 12 of RFCXXXX. 767 Interoperability considerations: the 3GPP Timed Text media format is 768 specified in 3GPP Release 5 version of TS 26.245 "Transparent end-to- 769 end packet switched streaming service (PSS); Timed Text Format 770 (Release 6)". In later releases, 3GPP may specify extensions or 771 updates to the media format in a backwards-compatible way, e.g. new 772 modifier boxes or extensions to the sample descriptions. The payload 773 format RFCXXXX allows for such extensions. For future 3GPP Releases 774 of the Timed Text Format, the therein parameters "brand", "mver" and 775 "cbrand" are used to identify the current version of the media 776 format, the oldest compatible version and a list of compatible 777 versions. 779 Published specification: RFC XXXX 781 Applications which use this media type: multimedia streaming 782 applications. 784 Additional information: the 3GPP Timed Text media format is specified 785 in 3GPP TS 26.245 "Transparent end-to-end packet switched streaming 786 service (PSS); Timed Text Format (Release 6)". This document and 787 future extensions to the 3GPP Timed Text format are publicly 788 available at http://www.3gpp.org. 790 Person & email address to contact for further information: 791 rey@panasonic.de 792 matsui.yoshinori@jp.panasonic.com 794 Intended usage: COMMON 796 Author/Change controller: 797 Jose Rey 798 Yoshinori Matsui 799 IETF AVT WG 801 9. SDP usage 803 This document defines the MIME subtype name "3gpp-tt" and introduces 804 several REQUIRED payload-format-specific parameters: "brand", 805 "width", "height", "tx", "ty", "layer", "spldesc" and "tx3g" and two 806 OPTIONAL parameters "mver" and "cbrand". 808 9.1 Mapping to SDP 810 The information carried in the MIME media type specification has a 811 specific mapping to fields in SDP [4], which is commonly used to 812 describe RTP sessions. When SDP is used to specify transmission 813 using this payload format, the mapping is done as follows: 815 - The MIME type ("video") goes in the SDP "m=" as the media name. 816 The "video" MIME Type is used as timed text is considered visual 817 media. 819 - The MIME subtype ("3gpp-tt") goes in SDP "a=rtpmap" as the 820 encoding name. The value timestamp clockrate is copied directly from 821 the 3GP file, the value of "timescale" in the Media Header Box is to 822 be used. Other values MAY be specified by out-of-band means. 824 - The REQUIRED payload-format-specific parameters "brand", "width", 825 "height", "tx", "ty", "layer", "tx3g" and "spldesc" go in the SDP 826 "a=fmtp" as a semicolon separated list of parameter= (or 827 parameter= for "tx3g") pairs. 829 - The OPTIONAL payload-format-specific parameters "mver", "cbrand" 830 go in the SDP "a=fmtp" as a semicolon-separated list of 831 parameter= pairs. 833 - Any remaining parameters go in the SDP "a=fmtp" attribute by 834 copying them directly from the MIME media type string as a semicolon 835 separated list of parameter=value pairs. 837 In the following sections some example SDP descriptions are 838 presented. 840 10. Examples of RTP packet structure 842 In this section, some examples of RTP packet structure are explained 843 for better understanding of this payload format. The wrap-around of 844 the long lines is indicated by the backslash character "\". The 845 examples assume aggregate control of stream container files. The 846 session descriptions are not complete but limited to the example 847 purposes. 849 10.1 An RTP packet containing multiple text samples 850 852 11. IANA Considerations 854 This document introduces the MIME subtype name "3gpp-tt" in Section 855 8. 857 12. Security considerations 859 RTP packets using the payload format defined in this specification 860 are subject to the security considerations discussed in the RTP 861 specification [3]. This implies that confidentiality of the media 862 streams is achieved by encryption. 864 Furthermore, the main security issues are confidentiality and 865 authentication of the text itself. The payload format itself does 866 not have any support for security. These issues have to be solved by 867 a payload external mechanism, e.g. SRTP [10]. 869 13. References 871 13.1 Normative References 873 1 3GPP, "Transparent end-to-end packet switched streaming service 874 (PSS); Timed Text Format (Release 6)", TS 26.245 v 0.1.6, Working 875 Draft, July 2003. 877 2 ISO/IEC 14496-1:2001/AMD5, "Information technology û Coding of 878 audio-visual objects û Part 1: Systems, ISO Base Media File 879 Format", 2003. 881 3 H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, "RTP: A 882 Transport Protocol for Real-Time Applications", RFC 3550, July 883 2003. 885 4 M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC 886 2327, April 1998. 888 5 S. Bradner, "Key words for use in RFCs to indicate requirement 889 levels," BCP 14, RFC 2119, IETF, March 1997. 891 13.2 Informative References 893 6 C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J.C. 894 Bolot, A. Vega-Garcia, S. Fosse-Parisis, "RTP Payload for 895 Redundant Audio Data", September 1997. 897 7 J. Rosenberg, H. Schulzrinne, "An RTP Payload Format for Generic 898 Forward Error Correction", RFC 2733, December 1999. 900 8 C. Perkins, O. Hodson, "Options for Repair of Streaming Media", 901 RFC 2354, June 1998. 903 9 W3C, "Synchronised Multimedia Integration Language (SMIL 2.0)", 904 August, 2001. 906 10 M. Baugher, D. A. McGrew, D. Oran, R. Blom, E. Carrara, M. 907 Naslund, K. Norrman, "The Secure Real-Time Transport Protocol", 908 draft-ietf-avt-srtp-05.txt, June 2002. 910 11 Handley, et al., "TCP Friendly Rate Control (TFRC): Protocol 911 Specification ", RFC 3448, January 2003. 913 12 R. Hovey, S. Bradner, "The Organizations involved in the IETF 914 Standards Process", BCP 11, RFC 2028, October 1996. 916 13 J. Rey et al., "RTP Retransmission Payload Format", draft-ietf- 917 avt-rtp-retransmission-10.txt, work in progress, January 2004. 919 14 M. Handley, C. Perkins, "Guidelines for Writers of RTP Payload 920 Format Specifications", RFC 2367, December 1999. 922 15 Van der Meer et al., "RTP Payload Format for Transport of MPEG-4 923 Elementary Streams ", RFC3640, November 2003. 925 14. Annex A Basics of 3GP File Structure 927 Each 3GP file consists of "Boxes". Boxes start with a header which 928 indicates both size and type contained. The 3GP file contains the 929 File Type Box (ftyp), the Movie Box (moov), and the Media Data Box 930 (mdat). The Movie Box and the Media Data Box, serving as containers, 931 include own boxes for each media. Similarly, each box type may 932 include a number of boxes, see ISO Base Media file Format [2] for a 933 complete list of possibilities. 935 In the following, only those boxes are mentioned, which are useful 936 for the purposes of this payload format. 938 The File Type Box identifies the type and properties of a 3GP file. 939 The File Type Box contents comprise the major brand, the minor 940 version and the compatible brands. These are communicated via out- 941 of-band means, such as SDP, when streamed with RTP. For the 3GPP 942 timed text file format, the set of compatible-brands MUST include 943 "3gp5". 945 The Movie Box contains one or more Track Boxes (trak) which include 946 information about each track. A Track Box contains, among others, 947 the Track Header Box (tkhd), the Media Header Box (mdhd) and the 948 Media Information Box (minf). The Media Header Box contains the 949 timescale or number of time units that pass in one second. The Media 950 Information Box includes the Sample Table Box (stbl) which itself 951 contains the Sample Description Box (stsd), the Decoding Time to 952 Sample Box (stts), the Sample Size Box (stsz) and the Sample to Chunk 953 Box (stsc). Sample descriptions for each text sample are encoded as 954 "tx3g" sample entries in the Sample Description Box (stsd). 956 The Track Header Box specifies the characteristics of a single track, 957 where a track is, in this case, the streamed text during a session. 958 Exactly one Track Header Box is needed for a track. It contains 959 information about the track, such as the spatial layout (width and 960 height), the video transformation matrix and the layer number. Since 961 these pieces of information are essential and static, i.e. constant 962 for the duration of the session, they MUST be sent prior to the 963 transmission of any text samples. See the ISO base media file format 964 [2] for details about the definition of the conveyed information. 966 When using scene description in SMIL [9], it is possible to specify 967 the layer and the position of the text track. However, in this case, 968 the transmission of the Track Header Box (tkhd) is still RECOMMENDED, 969 as the intrinsic track information is specified there. Otherwise, 970 the Track Header Box information MUST be sent prior to the start of 971 the text streaming. 973 The Sample Table Box (stbl) contains all the time and data indexing 974 of the media samples in a track. Using the tables here, it is 975 possible to locate samples in time, determine their type, and 976 determine their size, container, and offset into that container. 977 From the Sample Table Box (stbl) the following information is carried 978 in each RTP packet using this payload format: the Sample Description 979 Box (stsd), the Decoding Time to Sample Box (stts), the Sample Size 980 Box (stsz) and the Sample to Chunk Box (stsc). The Decoding Time to 981 Sample Box (stts) is mapped to the field SDUR (Text Sample Duration); 982 the Sample Size Box (stsz) is mapped the field SLEN (Text Sample 983 Length) and the Sample to Chunk Box is mapped to the field SIDX (Text 984 Sample Entry Index). The Sample to Chunk Box (stsc) associates the 985 text sample and its corresponding sample description entry in the 986 Sample Description Box (stsd, see below). The Sample to Chunk Box 987 can be used to associate a text sample with a sample description 988 entry. Since the sample description may vary during the session, the 989 association SDIX must be sent together with the text samples using 990 this payload format. 992 The Sample Description Box (stsd) provides information on the basic 993 characteristics of text samples. Each entry is a sample entry box of 994 type "tx3g". An example of the information contained in a sample 995 entry could be the font size or the background colour. Since these 996 pieces of information are commonly used by many text samples during 997 the session, it is sent by out-of-bands means. A complete list of 998 text characteristics can be found in [1]. 1000 Finally, the Media Data Box contains the media data itself. In 3GPP 1001 timed text tracks this box contains text samples. Its equivalent to 1002 audio and video is audio and video frames, respectively. The text 1003 sample consists of the text length, the text string, and one or 1004 several Modifier Boxes. The text length is the size of the text in 1005 bytes. The text string is plain text to render. The Modifier Box is 1006 information to render in addition to the text such as colour, font, 1007 etc. 1009 15. Author's Addresses 1011 Jose Rey rey@panasonic.de 1012 Panasonic European Laboratories GmbH 1013 Monzastr. 4c 1014 D-63225 Langen, Germany 1015 Phone: +49-6103-766-134 1016 Fax: +49-6103-766-166 1018 Yoshinori Matsui matsui.yoshinori@jp.panasonic.com 1019 Matsushita Electric Industrial Co., LTD. 1020 1006 Kadoma 1021 Kadoma-shi, Osaka, Japan 1022 Phone: +81 6 6900 9689 1023 Fax: +81 6 6900 9699 1025 16. IPR Notices 1027 The IETF takes no position regarding the validity or scope of any 1028 intellectual property or other rights that might be claimed to 1029 pertain to the implementation or use of the technology described in 1030 this document or the extent to which any license under such rights 1031 might or might not be available; neither does it represent that it 1032 has made any effort to identify any such rights. Information on the 1033 IETF's procedures with respect to rights in standards-track and 1034 standards-related documentation can be found in BCP 11 [12]. Copies 1035 of claims of rights made available for publication and any assurances 1036 of licenses to be made available, or the result of an attempt made to 1037 obtain a general license or permission for the use of such 1038 proprietary rights by implementers or users of this specification can 1039 be obtained from the IETF Secretariat. 1041 The IETF invites any interested party to bring to its attention any 1042 copyrights, patents or patent applications, or other proprietary 1043 rights which may cover technology that may be required to practice 1044 this standard. Please address the information to the IETF Executive 1045 Director. 1047 17. Full Copyright Statement 1049 "Copyright (C) The Internet Society (2003). All Rights Reserved. 1051 This document and translations of it may be copied and furnished to 1052 others, and derivative works that comment on or otherwise explain it 1053 or assist in its implementation may be prepared, copied, published 1054 and distributed, in whole or in part, without restriction of any 1055 kind, provided that the above copyright notice and this paragraph are 1056 included on all such copies and derivative works. However, this 1057 document itself may not be modified in any way, such as by removing 1058 the copyright notice or references to the Internet Society or other 1059 Internet organizations, except as needed for the purpose of 1060 developing Internet standards in which case the procedures for 1061 copyrights defined in the Internet Standards process must be 1062 followed, or as required to translate it into languages other than 1063 English. 1065 The limited permissions granted above are perpetual and will 1066 not be revoked by the Internet Society or its successors or 1067 assigns. 1069 This document and the information contained herein is provided on an 1070 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1071 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1072 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1073 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1074 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."