idnits 2.17.00 (12 Aug 2021) /tmp/idnits53198/draft-bormann-rohc-avt-rtcp-profile-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 610. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 621. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 628. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 634. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 26, 2007) is 5556 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 533 == Outdated reference: draft-ietf-rohc-rfc3095bis-framework has been published as RFC 4995 == Outdated reference: draft-ietf-rohc-rfc3095bis-rohcv2-profiles has been published as RFC 5225 == Outdated reference: A later version (-02) exists of draft-ietf-avt-rtcpxr-video-00 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Robust Header Compression C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Standards Track February 26, 2007 5 Expires: August 30, 2007 7 A ROHC Profile for RTCP (ROHC-RTCP) 8 draft-bormann-rohc-avt-rtcp-profile-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 30, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document specifies a ROHC (Robust Header Compression) profile 42 for compression of RTCP packets. The profile, called ROHC-RTCP, 43 provides efficient and robust compression of RTCP packets, including 44 frequently used RTCP features. 46 ROHC-RTCP is intended to be used in conjunction with ROHC profiles 47 for the compression of RTP headers such as RFC 3905 and ROHCv2, 48 making use of context replication (RFC 4164) where appropriate. In 49 particular, ROHC-RTCP is intended to remove the need for 50 standardization of special-purpose variants of RTCP for applications 51 just because these also need to work over low-speed links. 53 $Id: draft-bormann-rohc-avt-rtcp-profile.xml,v 1.11 2007/02/26 54 13:36:24 cabo Exp $ 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. Creating Contexts . . . . . . . . . . . . . . . . . . . . 4 62 3.2. Creating State . . . . . . . . . . . . . . . . . . . . . . 4 63 3.3. Using State . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4.1. Base Packet Formats . . . . . . . . . . . . . . . . . . . 5 66 4.2. CR Format . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4.3. ROHC-RTCP Body Format . . . . . . . . . . . . . . . . . . 6 68 4.4. Delta Format . . . . . . . . . . . . . . . . . . . . . . . 7 69 5. TBD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 6. Security considerations . . . . . . . . . . . . . . . . . . . 9 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 76 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 77 Appendix A. Bit-level Worked Example . . . . . . . . . . . . . . 11 78 Appendix B. Reference Implementation . . . . . . . . . . . . . . 11 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 Intellectual Property and Copyright Statements . . . . . . . . . . 15 82 1. Introduction 84 When the RTP profiles were defined for the ROHC framework, it was 85 considered unnecessary to provide compression for RTP's often 86 neglected child, RTCP. RTCP is designed to use only a small fraction 87 of the session bandwidth; any improvements from compressing it would 88 only occur within this small fraction. In addition, properly 89 compressing RTCP raised many questions that the ROHC designers were 90 not ready to answer in 2000. 92 Meanwhile, many creative uses for RTCP have been invented 93 [RFC4585][I-D.ietf-avt-rtcpxr-video]. Also, with the development of 94 context replication [RFC4164], the separation of the ROHC framework 95 [I-D.ietf-rohc-rfc3095bis-framework], and the development of ROHCv2 96 profiles [I-D.ietf-rohc-rfc3095bis-rohcv2-profiles], the time may be 97 ripe to address RTCP header compression. 99 This document defines a ROHC profile for compression of RTCP packets. 100 Note that there is little that could be called an RTCP header; 101 instead, for the purposes of this document, the entire RTCP packet 102 will be considered header information. 104 The profile indeed is not specific to RTCP: It could theoretically be 105 used to compress other recurring control information transmitted via 106 UDP. However, where design decisions have been made based on the 107 characteristics of this control information, this specification 108 focuses on RTCP. 110 2. Terminology 112 o State Item 114 Sequence of bytes that is established as a common state between 115 compressor and decompressor using ROHC methods. Within an RTCP 116 compression context, there may be multiple state items, which are 117 indexed by a state identifier. 119 o State Identifier 121 8-bit identifier for one of the state items that is part of the 122 current context. 124 3. Protocol Operation 126 This section gives an overview of the operation of ROHC-RTCP. 128 The ROHC-RTCP protocol behaves exactly like the ROHCv2 UDP protocol, 129 with the exceptions listed below. 131 3.1. Creating Contexts 133 A ROHC-RTCP context is created using an IR (initialization/refresh) 134 or a CR (context replication) packet (the latter is particularly 135 useful where an RTP HC context already exists for the RTP session). 137 For IR packets, the context created contains exactly the information 138 a ROHCv2 UDP context would contain, with the addition of a delta 139 format (see below). For CR packets, the provisions of [RFC4164] are 140 an integral part of this specification; again, the replicated context 141 is enhanced by a delta format. 143 When the context is created, a delta format is established for this 144 context; to minimize the change to the ROHCv2 headers, this is 145 specified in the Initial Byte of the Body Format, which replaces the 146 payload in all packet formats derived from ROHCv2. 148 3.2. Creating State 150 Every ROHC-RTCP packet supplies an 8-bit target state identifier. 151 The result of decompressing the packet is kept for future reference 152 under the state identifier supplied; any previous state item under 153 this state identifier is replaced. 155 Normal ROHC considerations apply about when a compressor can start to 156 rely on a state item to be present at the decompressor. As it is 157 based on ROHCv2, ROHC-RTCP supports the equivalent of unidirectional 158 and optimistic establishment of state items. 160 3.3. Using State 162 CO-type ROHC-RTCP packets reference an 8-bit state identifier and 163 supply a delta to the state item referenced as well as an 8-bit CRC. 164 The packet is decompressed by applying the supplied delta to the 165 state item referenced. If no state item exists at the decompressor 166 under the state identifier given or if checking the 8-bit CRC against 167 the decompressed packet fails, negative feedback is sent back to the 168 compressor (as described in the base ROHCv2 specification) and the 169 decompressed packet is discarded. 171 4. Packet Formats 173 This section defines the packet formats used in ROHC-RTCP. 175 4.1. Base Packet Formats 177 The ROHC-RTCP base packet format is exactly like the ROHCv2 UDP 178 format [I-D.ietf-rohc-rfc3095bis-rohcv2-profiles] with the following 179 exceptions: 181 1. There is a CR format, defined below. 182 2. Instead of the payload as defined in ROHCv2-UDP, the ROHC-RTCP 183 body format, defined below, is carried in ROHC-RTCP packets. 185 4.2. CR Format 187 A ROHC-RTCP CR header that references a ROHCv2 UDP context replicates 188 it as the basis for the ROHC-RTCP context. 190 A ROHC-RTCP CR header that references a [RFC3095] UDP context 191 replicates it as the basis for the ROHC-RTCP context, converting the 192 [RFC3095] UDP state to a ROHCv2 UDP state by discarding mode 193 information and converting the SN to an MSN. 195 A ROHC-RTCP CR header that references a ROHCv2 RTP context or a 196 [RFC3095] RTP context replicates/converts it as the basis for the 197 ROHC-RTCP context, removing the RTP specific information (and 198 creating an MSN out of the RTP SN for RFC3095). 200 The UDP part of the static chain of the context is then modified by 201 the port number pair given in the ROHC-RTCP CR header; all other 202 fields of the IP and the UDP headers are replicated from the base 203 context. 205 0 1 2 3 4 5 6 7 206 --- --- --- --- --- --- --- --- 207 : Add-CID octet : if for small CIDs and (CID != 0) 208 +---+---+---+---+---+---+---+---+ 209 | 1 1 1 1 1 1 0 x | IR type octet 210 +---+---+---+---+---+---+---+---+ 211 : : 212 / 0-2 octets of CID / 1-2 octets if for large CIDs 213 : : 214 +---+---+---+---+---+---+---+---+ 215 | Profile | 1 octet 216 +---+---+---+---+---+---+---+---+ 217 | y | CRC-7 | 1 octet 218 +---+---+---+---+---+---+---+---+ 219 : : 220 / 1-2 octets of base CID / 1-2 octets if for large CIDs 221 : : 222 +---+---+---+---+---+---+---+---+ 223 : src port : 2 octets 224 +---+---+---+---+---+---+---+---+ 225 : dst port : 2 octets 226 +---+---+---+---+---+---+---+---+ 227 | | 228 / ROHC-RTCP Body / variable length 229 | | 230 - - - - - - - - - - - - - - - - 232 For this version of the specification, x == 0 and y == 0. 234 4.3. ROHC-RTCP Body Format 236 ROHC-RTCP packets contain a ROHC-RTCP Body. 238 For CO packets, the ROHC-RTCP Body references a state item, the 239 identifier of which is given by the Initial Byte. For IR and CR 240 packets, the referenced state item is empty (a string of zero bytes). 242 (TBD: For CR, switching from ROHC-UDP to ROHC-RTCP may actually make 243 sense; in this case it may be useful to construct a different state 244 item, but this would assume there is information about a payload 245 available in a ROHC-UDP context.) 247 For IR and CR packets, the Initial Byte instead specifies the Delta 248 Format that is to be used for this context. 250 For the decompressed packet, the payload is reconstructed from the 251 state item and the payload delta using the delta format given (for IR 252 and CR packets) or established for this context (for CO packets). 254 0 1 2 3 4 5 6 7 255 +---+---+---+---+---+---+---+---+ 256 | Initial Byte | 1 octet 257 +---+---+---+---+---+---+---+---+ 258 | Target State Id | 1 octet 259 +---+---+---+---+---+---+---+---+ 260 | CRC | 1 octet 261 +---+---+---+---+---+---+---+---+ 262 | | 263 / Payload Delta / variable length 264 | | 265 - - - - - - - - - - - - - - - - 267 4.4. Delta Format 269 This specification only defines Delta Format 0x00. Additional Delta 270 Formats can be defined later; see Section 7 below. 272 Delta Format 0x00 is a sequence of byte codes, each of which 273 contributes to the output and/or modifies the interpretation state in 274 one of the following ways:: 275 1. Supplies additional bits to operands of subsequent byte codes. 276 2. Copies a specified number of bytes from the current state item to 277 the output and moves the current position in the current state 278 item forward by this number. 279 3. Copies a specified number of bytes from the Body itself to the 280 output, which are then skipped during interpretation 281 ("arguments"). The specified number of bytes must follow the 282 bytecode in the Body; an underrun causes decompression failure. 283 4. Modifies a specified number (m) of bytes from the state item in a 284 specified way: the m bytes are interpreted as a MSB-first binary 285 number and a number n is added to that number modulo 256^m; the 286 resulting number is copied in MSB-first form to the output. 287 5. Selects a different state item as the current state item. 288 6. Modifies the current position in the current state item in a 289 specified way, e.g., skips a specified number of bytes in the 290 state item (this position is only relevant for the purposes of 291 this single instance of delta format interpretation -- the 292 referenced state item is not itself modified). 294 The interpretation of bytecodes is finished (and the resulting output 295 processed as a payload) when the end of the Body is reached during 296 interpretation. 298 During interpretation of the byte codes, the decompressor maintains a 299 current position in each referenced state item. 301 If a byte code cannot be meaningfully interpreted, e.g. when the 302 bytes in the state item or the body run out prematurely, this causes 303 decompression failure, i.e. is treated like a CRC failure. 305 In the following table, some operations make use of a number n. The 306 number n is computed by appending the nnn bits in the current 307 bytecode to any accumulated prefix and adding one to the result. The 308 accumulated prefix starts out as an empty bitstring and is appended 309 to by one specific bytecode. If the concatenation of the accumulated 310 prefix and the nnn bits exceeds 16 bits, this is treated as 311 decompression failure. If there is an s bit in the bytecode, n is 312 negated (n = -n) if s == 1. Computing n always clears the 313 accumulated prefix value, if any. All bit operations are performed 314 most significant bit first. 316 Some operations make use of a number m. This number is computed from 317 mm as follows: m = mm+1. 319 Operations that use the "CSI" use the current state item, at the 320 current position noted for the current state item. The interpreter 321 maintains a separate position for the each state item that is used in 322 the bytecode; all positions are initialized to zero at the start of 323 interpreting each Body. Operations on the CSI number are modulo 256 324 (i.e., the CSI number is an 8-bit number). Operations on the 325 position in the CSI are modulo the size of the CSI in bytes. 327 Bytecode Arguments Semantics 328 000nnnnn (none) Append nnnnn to the accumulated prefix. 329 001nnnnn (none) Copy n bytes from CSI to output. 330 010nnnnn n bytes Copy n bytes from Body to output. 331 011mmsnn (none) Take m bytes from CSI, add n, output as m bytes. 332 10snnnnn (none) Add n to the CSI number, use as new CSI number. 333 11snnnnn (none) Change position in CSI by n, modulo size(CSI). 335 Note that implementations can represent n (including the accumulated 336 prefix) as a 16-bit value, as operations that would need more bits 337 are not meaningful or would even cause decompression failure. 338 Interpreting the change to the CSI position modulo the size of the 339 CSI (in bytes) means that all possible bit patterns are meaningful 340 (e.g., going beyond the end starts at the beginning again); to 341 simplify implementation of this case, accumulating large (more than 342 16-bit) values of n is simply disallowed (causes decompression 343 failure). 345 5. TBD 347 The following issues should be resolved for -01: 349 1. Delta formats are not yet subject to negotiation. 350 2. Is it entirely clear from the text that state items are per 351 context? Is that the right decision? 352 3. There probably needs to be some text about static/dynamic chains 353 in the packet formats. 354 4. Delta Format 0: It should be possible to refer to the packet 355 under construction as if it were a state item. (Another copy-n 356 instruction? And a goto instruction? Or clearing out the target 357 state ID? State ID 0?) 358 5. Do we really need two CRCs for CR? 359 6. Appendix A needs to be written. 361 6. Security considerations 363 The security considerations of [RFC3095] apply. An additional 364 denial-of-service attack is possible in ROHC-RTCP by filling up the 365 receiver with state items. The decompressor must be careful about 366 range-checking the Delta Format bytecode operations. As with all 367 compression protocols, the expansion that is likely to occur in 368 decompression can be used to amplify a denial-of-service attack. 369 (Note that bytecode interpretation is linear or sublinear to the 370 length of the bytecode -- there is no attack vector of overloading 371 the decompressor's CPU by sending looping or otherwise malformed 372 bytecode.) 374 7. IANA Considerations 376 The ROHC profile identifier 0x00XX [# Editor's Note: To be replaced 377 before publication #] has been reserved by the IANA for the profile 378 defined in this document. 380 The ROHC-RTCP delta format identifier 0x00 has been reserved by the 381 IANA for the ROHC-RTCP delta format 0x00 defined in this document. 383 [# Editor's Note: rest of this section to be removed before 384 publication: #] 386 A ROHC profile identifier must be reserved by the IANA for the new 387 profile defined in this document. A suggested registration in the 388 "RObust Header Compression (ROHC) Profile Identifiers" name space 389 would then be: 391 Profile Usage Reference 392 0x0009 ROHC RTCP [RFC XXXX (this)] 394 Author's note: This suggestion must be updated before sending to 395 IANA. 397 A new IANA registry "ROHC-RTCP delta formats" is established by this 398 specification under the regime "Standards Action required". 399 Initially, the value 0x00 is defined by this specification; further 400 values to be defined later need to be 8-bit numbers (values between 401 0x01 and 0xFF) and the pertinent standard needs to define the 402 semantics of the delta format to a similar effect as in Section 4.4 403 of this specification. 405 8. Contributors 407 The author would like to thank Joerg Ott, who noticed that this 408 profile was finally needed and supplied some sample data to be used 409 in appendix A. 411 Ghyslain Pelletier supplied comments that significantly shaped this 412 specification. Kristofer Sandlund's comments also pointed me in the 413 right direction. 415 9. Acknowledgements 417 A number of important concepts and ideas have been borrowed from ROHC 418 [RFC3095] and the ROHCv2 Internet-Drafts. 420 10. References 422 10.1. Normative References 424 [I-D.ietf-rohc-rfc3095bis-framework] 425 Jonsson, L., "The RObust Header Compression (ROHC) 426 Framework", draft-ietf-rohc-rfc3095bis-framework-01 (work 427 in progress), July 2006. 429 [I-D.ietf-rohc-rfc3095bis-rohcv2-profiles] 430 Pelletier, G. and K. Sandlund, "RObust Header Compression 431 Version 2 (RoHCv2): Profiles for RTP, UDP, IP, ESP and 432 UDP Lite", draft-ietf-rohc-rfc3095bis-rohcv2-profiles-00 433 (work in progress), September 2006. 435 [RFC4164] Pelletier, G., "RObust Header Compression (ROHC): Context 436 Replication for ROHC Profiles", RFC 4164, August 2005. 438 10.2. Informative References 440 [I-D.ietf-avt-rtcpxr-video] 441 Clark, A. and A. Pendleton, "RTCP XR - IP Video Metrics 442 Report Blocks", draft-ietf-avt-rtcpxr-video-00 (work in 443 progress), December 2006. 445 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 446 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 447 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 448 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 449 Compression (ROHC): Framework and four profiles: RTP, UDP, 450 ESP, and uncompressed", RFC 3095, July 2001. 452 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 453 "Extended RTP Profile for Real-time Transport Control 454 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 455 July 2006. 457 Appendix A. Bit-level Worked Example 459 This appendix gives a worked example at the bit level, showing how 460 various forms of RTCP packets are compressed by ROHC-RTCP. 462 TBD 464 Appendix B. Reference Implementation 466 This appendix gives a reference implementation of the delta format 467 decompressor. This appendix is intended to elucidate the normative 468 definition in Section 4.4 470 #!/usr/bin/env ruby 471 # 472 # $Id: decomp.rb,v 1.10 2007/02/25 13:27:48 cabo Exp $ 473 # 474 class DecompressionFailure < StandardError 475 end 477 class ROHC_RTCP 478 def initialize(delta_format = 0) 479 @delta_format = delta_format 480 @state_items = Hash.new { |h, k| h[k] = '' } 481 end 482 def state_item_is(n, si) 483 raise "Bad state item number #{n}" unless n >= 0 && n < 256 484 @state_items[n] = si 485 end 486 def pos 487 @state_pos[@csinum] 488 end 489 def pos=(np) 490 @state_pos[@csinum] = np 491 end 492 def csi 493 @state_items[@csinum] 494 end 495 def read_csi(nb) 496 out = csi[pos, nb] 497 self.pos += nb 498 raise DecompressionFailure unless out.size == nb 499 out 500 end 501 def n(op, bits, s = 0) 502 out = (@accum << bits) | (op & ((1 << bits) - 1)) 503 @accum = 0 504 raise DecompressionFailure unless out < 0x10000 # 16 bits 505 out += 1 506 out = -out if s[bits] != 0 507 out 508 end 509 def decompress(bo, refsi) 510 raise DecompressionFailure unless @delta_format == 0 511 out = '' 512 @accum = 0 513 @csinum = refsi 514 @state_pos = Hash.new(0) 515 i = 0 516 while i < bo.size 517 op = bo[i]; i += 1 518 case op >> 5 519 when 0b000 520 @accum = (@accum << 5) | (op & ((1 << 5) - 1)) 521 when 0b001 522 out << read_csi(n(op, 5)) 523 when 0b010 524 nb = n(op, 5) 525 out << bo[i, nb] 526 i += nb 527 raise DecompressionFailure unless i <= bo.size 528 when 0b011 529 delta = n(op, 2, op) 530 nb = ((op >> 3) & 3) + 1 531 val = read_csi(nb) 532 val = ("\0" * (4-nb)) + val 533 val = val.unpack('N')[0] + delta 534 out << [val].pack('N')[4-nb, nb] 535 when 0b100, 0b101 536 @csinum += n(op, 5, op) 537 @csinum &= 0xff 538 when 0b110, 0b111 539 self.pos += n(op, 5, op) 540 self.pos %= csi.size 541 end 542 end 543 out 544 end 545 end 547 if $0 == __FILE__ # test harness 548 def decode(s) # allow binary and character input 549 out = '' 550 s.scan(/\s*([01]{8}\s*)|(.)/) do |b, c| 551 out << (b ? b.to_i(2).chr : c) 552 end 553 out 554 end 555 r = ROHC_RTCP.new 556 expect = '' 557 DATA.each do |l| 558 l.chomp! 559 case l 560 when /^s (\d+) (.*)$/ # init state item 561 r.state_item_is($1.to_i, $2) 562 when /^e (.*)$/ # expect result 563 expect = decode($1) 564 when /^f$/ # expect failure 565 expect = nil 566 when /^d (\d+) (.*)$/ # decompress 567 refsi = $1.to_i 568 testdata = decode($2) 569 begin 570 out = r.decompress(testdata, refsi) 571 rescue DecompressionFailure 572 out = nil 573 end 574 puts "#{testdata.inspect} => #{out.inspect} -- " + 575 (expect == out ? 'OK' : "ERROR: Expecting #{expect.inspect}") 576 when /^\s*$/, /^#.*$/ # space, comments 577 else 578 raise "Bad test line #{l}" 579 end 581 end 582 end 584 Author's Address 586 Carsten Bormann 587 Universitaet Bremen TZI 588 Postfach 330440 589 Bremen D-28334 590 Germany 592 Phone: +49 421 218 7024 593 Fax: +49 421 218 7000 594 Email: cabo@tzi.org 596 Full Copyright Statement 598 Copyright (C) The IETF Trust (2007). 600 This document is subject to the rights, licenses and restrictions 601 contained in BCP 78, and except as set forth therein, the authors 602 retain all their rights. 604 This document and the information contained herein are provided on an 605 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 606 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 607 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 608 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 609 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 610 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 612 Intellectual Property 614 The IETF takes no position regarding the validity or scope of any 615 Intellectual Property Rights or other rights that might be claimed to 616 pertain to the implementation or use of the technology described in 617 this document or the extent to which any license under such rights 618 might or might not be available; nor does it represent that it has 619 made any independent effort to identify any such rights. Information 620 on the procedures with respect to rights in RFC documents can be 621 found in BCP 78 and BCP 79. 623 Copies of IPR disclosures made to the IETF Secretariat and any 624 assurances of licenses to be made available, or the result of an 625 attempt made to obtain a general license or permission for the use of 626 such proprietary rights by implementers or users of this 627 specification can be obtained from the IETF on-line IPR repository at 628 http://www.ietf.org/ipr. 630 The IETF invites any interested party to bring to its attention any 631 copyrights, patents or patent applications, or other proprietary 632 rights that may cover technology that may be required to implement 633 this standard. Please address the information to the IETF at 634 ietf-ipr@ietf.org. 636 Acknowledgment 638 Funding for the RFC Editor function is provided by the IETF 639 Administrative Support Activity (IASA).