idnits 2.17.1 draft-xie-avt-compact-bundle-evrc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 526. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 503. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 510. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 516. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (September 23, 2005) is 6790 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: '1' is defined on line 440, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2327 (ref. '8') (Obsoleted by RFC 4566) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Q. Xie 3 Internet-Draft Motorola 4 Expires: March 27, 2006 R. Kapoor 5 Qualcomm 6 September 23, 2005 8 Enhancements to RTP Format for EVRC Family Codecs 9 draft-xie-avt-compact-bundle-evrc-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 27, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document defines several enhancements and extensions to RFC3558 43 EVRC RTP payload format. In particular, it defines the support for a 44 compact bundled format and EVRC-B codec, as well as discontinuous 45 transmission (DTX) support for EVRC and EVRC-B encoded speech 46 transported via RTP sessions. Some VoIP applications, such as Push- 47 to-Talk and VoIP over low bandwidth dial-up and wireless networks, 48 require such enhancements for efficient use of the bandwidth. 50 Table of Contents 52 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1 Support of EVRC-B Codec . . . . . . . . . . . . . . . . . 3 55 2.2 Compact (Header-free) Bundled Format . . . . . . . . . . . 3 56 2.3 Discontinuous Transmission (DTX) . . . . . . . . . . . . . 4 57 3. EVRC-B Codec . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Compact Bundled Format . . . . . . . . . . . . . . . . . . . . 5 59 4.1 Single Rate Operation . . . . . . . . . . . . . . . . . . 5 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 5.1 Registration of Media Type EVRCB . . . . . . . . . . . . . 6 62 5.2 Registration of Media Type EVRC1 and EVRCB1 . . . . . . . 6 63 5.3 Payload Format Parameters for DTX . . . . . . . . . . . . 8 64 5.4 Mapping MIME Parameters into SDP . . . . . . . . . . . . . 9 65 5.5 Usage in Offer/Answer . . . . . . . . . . . . . . . . . . 10 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 7.1 Normative References . . . . . . . . . . . . . . . . . . . 10 69 7.2 Informative References . . . . . . . . . . . . . . . . . . 11 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 71 Intellectual Property and Copyright Statements . . . . . . . . 12 73 1. Conventions 75 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 76 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 77 they appear in this document, are to be interpreted as described in 78 [2]. 80 2. Introduction 82 This document defines several enhancements and extensions to RFC3558 83 EVRC RTP payload format [5]. In particular, it defines the support 84 for a compact bundled format and EVRC-B codec, as well as 85 discontinuous transmission (DTX) support for EVRC and EVRC-B encoded 86 speech transported via RTP sessions. Some VoIP applications, such as 87 Push-to-Talk and VoIP over low bandwidth dial-up and wireless 88 networks, require such enhancements for efficient use of the 89 bandwidth. 91 2.1 Support of EVRC-B Codec 93 EVRC-B [4] is an extension to [3] developed in 3GPP2. EVRC-B [4] 94 compresses each 20 milliseconds of 16-bit sampled speech input into 95 output frames of one of the four different sizes: Rate 1 (171 bits), 96 Rate 1/2 (80 bits), Rate 1/4 (40 bits), or Rate 1/8 (16 bits). In 97 addition, there are two zero bit codec frame types: null frames and 98 erasure frames, similar to EVRC [3]. One significant enhancement in 99 EVRC-B is that there are Rate 1/4 frames that were not used in EVRC. 100 This provides lower average data rates (ADRs) compared to EVRC, for a 101 given voice quality. 103 Since EVRC-B encoded speech frames are different from those of EVRC, 104 EVRC-B and EVRC codecs do not interoperate with each other. At the 105 initiation of a RTP session, the RTP sender and receiver need to 106 indicate (e.g., using MIME subtypes that are separate from those of 107 EVRC) that EVRC-B is to be used for the ensuing session. 109 2.2 Compact (Header-free) Bundled Format 111 The current interleaved/bundled packet format defined in RFC 3558 112 allows bundling of multiple speech frames of different rate in a 113 single RTP packet, sending rate change request, and interleaving. To 114 support these functions, a Table of Content (ToC) is used in each RTP 115 packet in addition to the standard RTP header. The size of the ToC 116 is variable, depending on the number of EVRC frames carried in the 117 packet [5]. 119 The current header-free packet format defined in RFC 3558 is more 120 compact and optimized for use over wireless links. It eliminates the 121 need for a ToC by requiring that each RTP packet contains only one 122 speech frame (of any allowable rate), i.e., bundling is not allowed. 123 Moreover, interleaving and rate change request are not supported in 124 the header-free format [5]. 126 Since the biggest EVRC/EVRC-B speech frame is 171 bits (full rate), 127 it is therefore very inefficient in terms of bandwidth utilization to 128 send EVRC/EVRC-B speech frames one at a time over RTP/UDP/IP, as 129 being required by the header-free format. It is assumed that this 130 shortcoming of the header-free format will be overcome or at least 131 greatly alleviated in practice by the use of RTP/UDP/IP header 132 compression or removal techniques such as ROHC [9]. 134 However, in many wireless systems such as 3GPP and 3GPP2, header 135 compression/removal is only applied between the mobile station and 136 the radio access network. ROHC is not an end-to-end compression 137 scheme, there will be many hops between the EVRC/EVRC-B sender and 138 the EVRC/EVRC-B receiver where such overheads may be an issue. As 139 speech will be carried one speech frame per RTP packet with full RTP/ 140 UDP/IP headers, it would result in very poor bandwidth utilization in 141 that part of the network. 143 The compact bundled format described in this document presents the 144 user an alternative to the header-free format defined in RFC 3558. 145 The compact bundled format is wireless-friendly since it does not use 146 a ToC. It also allows bundling of multiple EVRC or EVRC-B frames and 147 will not create bandwidth inefficiency problems in the network. 148 However, to use this compact bundled format the compromise one has to 149 make is that only one EVRC/EVRC-B rate (full rate or 1/2 rate) can be 150 used in the session. Similar to the header-free format defined in 151 RFC 3558, interleaving and rate change request are not supported in 152 the compact bundled format. 154 2.3 Discontinuous Transmission (DTX) 156 Originally, EVRC codec did not provide DTX support; in variable rate 157 operation mode the encoder sends 1/8 rate frames during periods of 158 silence, while in single rate operation mode (see 4.1 ???), silence 159 is encoded and sent in silence frames of the same rate as that of 160 speech frames. 162 Silence or 1/8 rate frames of EVRC and EVRC-B codecs vary little 163 during periods of silence. The transmission of these 1/8 rate frames 164 (or silence frames in the single rate operation mode) across the 165 radio interface in a wireless system is expensive in terms of 166 capacity, and therefore, suppression of these frames is desirable. 168 Suppression of silence frames is accomplished using DTX. When DTX is 169 applied, the first few 1/8 rate frames (or silence frames in the 170 single rate operation mode) are transmitted to establish background 171 noise during the period of silence. Then a portion of the stream of 172 subsequent 1/8 rate frames (or silence frames in the single rate 173 operation mode) are not transmitted and discarded at the encoder. At 174 the receiver, background or comfort noise should be created by using 175 the previously received 1/8th rate frames (or silence frames in the 176 single rate operation mode). 178 3. EVRC-B Codec 180 Two RTP modes are supported for EVRC-B codec - the interleaved/ 181 bundled packet format and compact bundled packet format. For the 182 interleaved/bundled packet format, the operational details and 183 capabilities, such as ToC, interleaving, and bundling, of EVRC-B are 184 exactly the same as those of EVRC, as defined in RFC3558 [5]. The 185 compact bundled packet format for EVRC-B is defined in Section 4 of 186 this document. 188 4. Compact Bundled Format 190 A packet in the compact bundled format consists of an RTP header 191 followed by a sequence of one or more consecutive EVRC/EVRC-B codec 192 data frames of the same rate, as shown below: 194 0 1 2 3 195 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 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | RTP Header [4] | 198 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 199 | | 200 | One or more EVRC/EVRC-B data frames of same rate | 201 | .... | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 The vocoder date frames MUST be generated from the output of the 205 vocoder following the procedure described in 5.2 in RFC 3558 [5] and 206 they all MUST be of the same rate and size. 208 4.1 Single Rate Operation 210 As mentioned earlier, to use the compact bundled format, all the 211 EVRC/EVRC-B data frames in the session MUST be of the same rate 212 (either 1 or 1/2 rate). To some VoIP applications, such as Push-to- 213 Talk over cellular, this is not viewed as much of a limitation due to 214 their unique communication style where rate changes in a session are 215 often difficult and sometimes even undesirable. 217 For a session that uses the compact bundled format, the rate for the 218 session can be determined during the session setup signaling, for 219 example, via SDP exchanges. See Section 5 below for more details. 221 5. IANA Considerations 223 Three (3) new MIME subtype registration are required for the EVRC-B 224 support and compact bundled format payload types, and four (4) 225 optional parameters - "silencesupp", "dtxmax", "dtxmin", and 226 "hangover" - are defined and used in DTX, as described below. 228 5.1 Registration of Media Type EVRCB 230 Media Type name: audio 232 Media subtype names: EVRCB 234 Required parameters: none 236 Optional parameters: see RFC 3558 [5]. 238 Encoding considerations: This media type is defined for transfer of 239 EVRC-B encoded data via RTP using the Interleaved/Bundled packet 240 format specified in RFC 3558 [5] and RFC XXXX. 242 Security considerations: See Section 7 of RFC XXXX. 244 Public specification: The EVRC-B vocoder is specified in 3GPP2 245 C.S0014-B [4]. Transfer method with Interleaved/Bundled packet 246 format via RTP is specified in RFC 3558 and RFC XXXX. 248 Person & email address to contact for further 249 information: Qiaobing.Xie@motorola.com 251 Intended usage: COMMON. It is expected that many VoIP applications 252 (as well as mobile applications) will use this type. 254 Author/Change controller: 256 * Qiaobing.Xie@motorola.com 258 * IETF Audio/Video transport working group 260 5.2 Registration of Media Type EVRC1 and EVRCB1 261 Media Type name: audio 263 Media subtype names: EVRC1, EVRCB1 265 Required parameters: none 267 Optional parameters: 269 ptime: see RFC 2327 [8]. 271 maxptime: The maximum amount of media which can be encapsulated in 272 each packet, expressed as time in milliseconds. The time SHALL be 273 calculated as the sum of the time the media present in the packet 274 represents. The time SHOULD be a multiple of the duration of a 275 single codec data frame (20 msec). If not signaled, the default 276 maxptime value SHALL be 200 milliseconds. 278 evrcfixedrate: Indicates the EVRC/EVRC-B rate of the session while in 279 single rate operation. Valid values for EVRC1 and EVRCB1 subtype 280 include: 0.5 and 1, where a value of 0.5 indicates the 1/2 rate 281 while a value of 1 indicates the full rate. If this parameter is 282 not present, 1/2 rate is assumed. 284 Encoding considerations: These types are defined for transfer of EVRC 285 or EVRC-B encoded data via RTP using the compact bundled format as 286 described in RFC XXXX. 288 Security considerations: See Section 7 of RFC XXXX. 290 Public specification: The EVRC and EVRC-B vocoders are specified in 291 3GPP2 C.S0014 and 3GPP-2 C.S0014-B, respectively. Transfer method 292 with compact bundled RTP format is specified in RFC XXXX. 294 Person & email address to contact for further 295 information: Qiaobing.Xie@motorola.com 297 Intended usage: COMMON. It is expected that many VoIP applications 298 (as well as mobile applications) will use this type. 300 Author/Change controller: 302 * Qiaobing.Xie@motorola.com 304 * IETF Audio/Video transport working group 306 5.3 Payload Format Parameters for DTX 308 For all the EVRC and EVRC-B RTP payload formats defined in RFC 3558 309 [5] and RFC XXXX, four additional optional parameters - 310 "silencesupp", "dtxmax", "dtxmin", and "hangover" - are defined and 311 used in DTX, as described below. 313 silencesupp: Permissible values are 0 and 1. A value of 1 indicates 314 the sender's ability and desire to support silence suppression 315 using DTX. A value of 0 or when not present, it indicates that 316 the sender is either incapable or unwilling to use silence 317 suppression using DTX. Unless indicated by both the RTP sender 318 and receiver, silence suppression using DTX MUST NOT be used for 319 the session. 321 dtxmax: indicates the maximum number of 1/8 rate frames (or silence 322 frames in the single rate operation mode) that may be continuously 323 suppressed and thus provides a "keep alive" function to the 324 bearer. When setting up an RTP session that uses DTX, an RTP 325 receiver can use this parameter to signal the maximum number of 326 1/8 rate frames (or silence frames in the single rate operation 327 mode) that may be continuously suppressed by the RTP sender. If 328 this parameter is not present for a session that uses DTX, the 329 default value MUST be assumed. This parameter MUST be ignored if 330 silence suppression using DTX is not used for the session. 331 [Editor's note: Default value is 50 and will be specified in a 332 3GPP2 TSG-C 1.1 document]. 334 dtxmin: indicates the minimum number of contiguous 1/8 rate frames 335 (or silence frames in the single rate operation mode) that MUST be 336 suppressed when they occur in the output of the codec. When 337 setting up an RTP session that uses DTX, an RTP receiver can use 338 this parameter to signal the minimum number of contiguous 1/8 rate 339 frames (or silence frames in the single rate operation mode) that 340 SHOULD be suppressed by the RTP sender. If this parameter is not 341 present for a session that uses DTX, the default value MUST be 342 assumed. This parameter MUST be ignored if silence suppression 343 using DTX is not used for the session. [Editor's note: Default 344 value is 8 and will be specified in a 3GPP2 TSG-C 1.1 document.] 346 hangover: indicates the number of 1/8 rate frames (or silence frames 347 in the single rate operation mode) transmitted at the end of 348 active speech but before DTX actions begin. When setting up an 349 RTP session that uses DTX, an RTP receiver can use this parameter 350 to signal the number of 1/8 rate frames (or silence frames in the 351 single rate operation mode) that SHOULD be transmitted by the RTP 352 sender prior to beginning DTX actions. If this parameter is not 353 present for a session that uses DTX, the default value SHOULD be 354 assumed. This parameter MUST be ignored if silence suppression 355 using DTX is not used for the session. [Editor's note: Default 356 value is 2 and will be specified in a 3GPP2 TSG-C 1.1 document.] 358 Additionally, the RTP marker (M) bit MUST be used by the RTP senders 359 to indicate that a DTX interval may begin. The marker bit may be 360 used by RTP receivers in order to assist in managing the play-out 361 buffers. In particular, the M bit MUST be set to '1' to indicate 362 that discontinuous transmission may begin with the next packet and 363 MUST be set to '0' otherwise. [Editor's note: This is still very 364 confusing. There is no specific behavior of the receiver being 365 requested here. Either this will be clarified in the following 366 revisions or this para will be removed.] 368 5.4 Mapping MIME Parameters into SDP 370 The information carried in the MIME media type specification has a 371 specific mapping to fields in the Session Description Protocol (SDP) 372 [8], which is commonly used to describe RTP sessions. When SDP is 373 used to specify sessions employing the compact bundled format for 374 EVRC/EVRC-B encoded speech, the mapping is as follows: 376 o The MIME type ("audio") goes in SDP "m=" as the media name. 378 o The MIME subtype ("EVRCB", "EVRC1", or "EVRCB1") goes in SDP 379 "a=rtpmap" as the encoding name. 381 o The optional parameters "ptime" and "maxptime" go in the SDP 382 "a=ptime" and "a=maxptime" attributes, respectively. 384 o The optional parameter "evrcfixedrate" (for subtypes EVRC1 and 385 EVRCB1) goes in "a=fmtp" attribute by copying it directly from the 386 MIME media type string as "evrcfixedrate=value". 388 o The optional parameters "silencesupp", "dtxmax", "dtxmin", and 389 "hangover" go in "a=fmtp" attribute by copying it directly from 390 the MIME media type string as "silencesupp=value", "dtxmax=value", 391 "dtxmin=value", and "hangover=value", respectively. 393 Example of usage of EVRCB: 395 m=audio 49120 RTP/AVP 97 396 a=rtpmap:97 EVRCB/8000 397 a=maxptime:120 399 Example of usage of EVRC1: 401 m=audio 49120 RTP/AVP 97 402 a=rtpmap:97 EVRC1/8000 403 a=fmtp:97 evrcfixedrate=0.5 404 a=maxptime:120 406 Example of usage of EVRCB1: 408 m=audio 49120 RTP/AVP 97 409 a=rtpmap:97 EVRCB1/8000 410 a=fmtp:97 evrcfixedrate=0.25 411 a=maxptime:100 413 Example of usage of EVRC1 with DTX: 415 m=audio 49120 RTP/AVP 97 416 a=rtpmap:97 EVRC1/8000 417 a=fmtp:97 evrcfixedrate=0.5 418 a=fmtp:97 silencesupp=1 dtxmax=50 dtxmin=8 hangover=2 419 a=maxptime:120 421 5.5 Usage in Offer/Answer 423 All SDP parameters in this payload format are declarative, and all 424 reasonable values are expected to be supported. Thus, the standard 425 usage of Offer/Answer as described in RFC 3264 [7] should be 426 followed. 428 6. Security Considerations 430 Implementations using the payload defined in this specification are 431 subject to the security considerations discussed in the RTP 432 specification RFC 3550 [6] and any appropriate profile (for example 433 RFC3551 [10]). This payload does not specify any different security 434 services. 436 7. References 438 7.1 Normative References 440 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 441 BCP 9, RFC 2026, October 1996. 443 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 444 Levels", BCP 14, RFC 2119, March 1997. 446 [3] "Enhanced Variable Rate Codec, Speech Service Option 3 for 447 Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014, 448 January 1997. 450 [4] "Enhanced Variable Rate Codec, Speech Service Option XX for 451 Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014-B, in 452 progress. 454 [5] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs 455 (EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558, July 2003. 457 [6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 458 "RTP: A Transport Protocol for Real-Time Applications", 459 RFC 3550, July 2003. 461 [7] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 462 the Session Description Protocol (SDP)", RFC 3264, June 2002. 464 [8] Handley, M. and V. Jacobson, "SDP: Session Description 465 Protocol", RFC 2327, April 1998. 467 7.2 Informative References 469 [9] Bormann, C., "RObust Header Compression (ROHC): Framework and 470 four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, 471 July 2001. 473 [10] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 474 Conferences with Minimal Control", RFC 3551, July 2003. 476 Authors' Addresses 478 Qiaobing Xie 479 Motorola, Inc. 480 1501 W. Shure Drive, 2-F9 481 Arlington Heights, IL 60004 482 US 484 Phone: +1-847-632-3028 485 Email: qxie1@email.mot.com 487 Rohit Kapoor 488 Qualcomm Inc. 489 US 491 Phone: +1-858-845-1161 492 Email: rkapoor@qualcomm.com 494 Intellectual Property Statement 496 The IETF takes no position regarding the validity or scope of any 497 Intellectual Property Rights or other rights that might be claimed to 498 pertain to the implementation or use of the technology described in 499 this document or the extent to which any license under such rights 500 might or might not be available; nor does it represent that it has 501 made any independent effort to identify any such rights. Information 502 on the procedures with respect to rights in RFC documents can be 503 found in BCP 78 and BCP 79. 505 Copies of IPR disclosures made to the IETF Secretariat and any 506 assurances of licenses to be made available, or the result of an 507 attempt made to obtain a general license or permission for the use of 508 such proprietary rights by implementers or users of this 509 specification can be obtained from the IETF on-line IPR repository at 510 http://www.ietf.org/ipr. 512 The IETF invites any interested party to bring to its attention any 513 copyrights, patents or patent applications, or other proprietary 514 rights that may cover technology that may be required to implement 515 this standard. Please address the information to the IETF at 516 ietf-ipr@ietf.org. 518 Disclaimer of Validity 520 This document and the information contained herein are provided on an 521 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 522 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 523 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 524 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 525 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 526 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 528 Copyright Statement 530 Copyright (C) The Internet Society (2005). This document is subject 531 to the rights, licenses and restrictions contained in BCP 78, and 532 except as set forth therein, the authors retain all their rights. 534 Acknowledgment 536 Funding for the RFC Editor function is currently provided by the 537 Internet Society.