idnits 2.17.1 draft-roach-sigcomp-nack-01.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 289: '...compression failure MUST set the least...' RFC 2119 keyword, line 294: '...e extensions and MUST be ignored for t...' 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 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 (March 2002) is 8078 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) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. B. Roach 3 Internet-Draft dynamicsoft 4 Expires: August 30, 2002 March 2002 6 A Negative Acknowledgement Mechanism for Signalling Compression 7 draft-roach-sigcomp-nack-01 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on August 30, 2002. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 This document describes a mechanism that allows Signalling 39 Compression (SigComp) implementations to report precise error 40 information upon receipt of a message which cannot be decompressed. 41 This negative feedback can be used by the recipient to make fine- 42 grained adjustments to the compressed message before retransmitting 43 it, allowing for rapid and efficient recovery from error situations. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.1 The Problem . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1.1 Compartment Disposal . . . . . . . . . . . . . . . . . . . . 3 50 1.1.2 Client Restart . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1.3 Server Failover . . . . . . . . . . . . . . . . . . . . . . 4 52 1.2 The Solution . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Node Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 54 2.1 Normal SigComp Message Transmission . . . . . . . . . . . . 5 55 2.2 Receiving a "Bad" SigComp Message . . . . . . . . . . . . . 5 56 2.3 Receiving a SigComp NACK . . . . . . . . . . . . . . . . . . 6 57 2.3.1 Unreliable Transport . . . . . . . . . . . . . . . . . . . . 6 58 2.3.2 Reliable Transport . . . . . . . . . . . . . . . . . . . . . 6 59 2.4 Detecting Support for NACK . . . . . . . . . . . . . . . . . 7 60 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 8 61 3.1 Message Fields . . . . . . . . . . . . . . . . . . . . . . . 8 62 3.2 Reason Codes . . . . . . . . . . . . . . . . . . . . . . . . 10 63 4. Security Considerations . . . . . . . . . . . . . . . . . . 14 64 4.1 Reflector Attacks . . . . . . . . . . . . . . . . . . . . . 14 65 4.2 NACK Spoofing . . . . . . . . . . . . . . . . . . . . . . . 14 66 Normative References . . . . . . . . . . . . . . . . . . . . 15 67 Non-Normative References . . . . . . . . . . . . . . . . . . 16 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . 16 69 A. Comments and Feedback . . . . . . . . . . . . . . . . . . . 17 70 B. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 18 71 Full Copyright Statement . . . . . . . . . . . . . . . . . . 19 73 1. Introduction 75 Signalling Compression (see reference [1]), often called "SigComp", 76 defines a protocol for transportation of compressed messages between 77 two network elements. One of the key features of SigComp is the 78 ability of the sending node to request that the receiving node store 79 state objects for later retrieval. 81 1.1 The Problem 83 While the "SigComp - Extended Operations" document (reference [2]) 84 defines a mechanism that allows for confirmation of state creation, 85 operational experience with the SigComp protocol has demonstrated 86 that there are still several circumstances in which a sender's view 87 of the shared state differs from the reciever's view. A non- 88 exhaustive list of the circumstances in which such failures may occur 89 are detailed below. 91 1.1.1 Compartment Disposal 93 In SigComp, stored states are associated with compartments. 94 Conceptually, the compartments represent one instance of a remote 95 application. These compartments are used to limit the amount of 96 state that each remote application is allowed to store. Compartments 97 are created upon receipt of a valid SigComp message from a remote 98 application. In the current protocol, applcations are expected to 99 signal when they are finished with a compartment so that it can be 100 deleted (by using the S-bit in requested feedback data). 102 Unfortunately, expecting the applications to be well-behaved is not 103 sufficient to prevent state from piling up. Unexpected client 104 failures, reboots, and loss of connectivity can cause compartments to 105 become "stuck" and never removed. To prevent this situation, it 106 becomes necessary to implement a scheme by which compartments that 107 appear disused may eventually be discarded. 109 While the preceding facts make such a practice necessary, discarding 110 compartments without explicit signalling can have the unfortunate 111 side effect that active compartments are sometimes discarded. This 112 leads to a different view of state between the server and the client. 114 1.1.2 Client Restart 116 The prime motivation behind SigComp was compression of messages to be 117 sent over a radio interface. Consequently, most deployments of 118 SigComp will involve a mobile unit as one of the the endpoints. Such 119 units are not generally highly available. Node restarts (due to e.g. 120 a battery running out) will induce situations in which the network- 121 based server beleives that the client contains several states that 122 are no longer actually available. 124 1.1.3 Server Failover 126 Many applications for which SigComp will be used (e.g., SIP [3]) use 127 DNS SRV records for server lookup. One of the important features of 128 DNS SRV records is the ability to specify multiple servers from which 129 clients will select at random, with probabilities determined by the 130 q-value weighting. The reason for defining this behavior for SRV 131 records is to allow load distribution through a set of equivalent 132 servers, and to permit clients to continue to function even if the 133 server with which they are communicating fails. When using protocols 134 that use SRV for such distribution, the traffic to a failed server is 135 typically sent by the client to an equivalent server that can serve 136 the same purpose. From an application perspective, this new server 137 often appears to be the same endpoint as the failed server, and will 138 consequently resolve to the same compartment. 140 Although SigComp state can be replicated amongst such a cluster of 141 servers, maintaining integrity of such states requires a two-phase 142 commit process, which adds a great deal of complexity to the server, 143 and can degrade performance significantly. 145 1.2 The Solution 147 Although SigComp allows returned SigComp parameters to signal that 148 all states have been lost (by setting "state_memory_size" to 0 for 149 one message in the reverse direction), such an approach provides an 150 incomplete solution to the problem. In addition to wiping out an 151 entire compartment when only one state is corrupt or missing, this 152 approach suffers from the unfortunate behavior that it requires a 153 message in the reverse direction that the remote application will 154 authorize. Unless a lower-layer security mechanism is employed (e.g. 155 TLS), this would typically mean that a compressed application-level 156 message in the reverse direction must be sent before recovery can 157 occur. In many cases, such as SIP-based mobile terminals, such 158 messages may be seldom; in others (pure client/server deployments), 159 they won't ever happen. 161 The proposed solution to this problem is a simple Negative 162 Acknowledgement (NACK) mechanism which allows the recipient to 163 communicate to the sender that a failure has occured. This NACK 164 contains a reason code that communicates the nature of the failure. 165 For certain types of failures, the NACK will also contain additional 166 details that might be useful in recovering from the failure. 168 2. Node Behavior 170 The following sections detail the behavior of nodes sending and 171 receiving SigComp NACKs. The actual format and values are described 172 in section Section 3. 174 2.1 Normal SigComp Message Transmission 176 Although normal in all other respects, SigComp implementations that 177 use the NACK mechanism need to calculate and store a SHA-1 hash for 178 each SigComp message that they send. This must be stored in such a 179 way that, given the SHA-1 hash, the implementation is able to locate 180 the compartment with which the sent message was associated. Further, 181 when a reliable transport is being used, the implementation must be 182 able to retrieve the plain-text version of the original message. 184 2.2 Receiving a "Bad" SigComp Message 186 When a received SigComp message causes a decompression failure, the 187 recipient forms and sends a SigComp NACK message. This NACK message 188 contains a SHA-1 hash of the received SigComp message that could not 189 be decompressed. It also contains the exact reason decompression 190 failed, as well as any additional details that might assist the NACK 191 recipient to correct any problems. See section Section 3 for more 192 information about formatting the NACK message and its fields. 194 For a connection-oriented transport, such as TCP, the NACK message is 195 sent back to the originator of the failed message over that same 196 connection. 198 For a stream-based transport, such as TCP, the standard SigComp 199 delimiter of 0xFFFF is used to terminate the NACK message. 201 For a connectionless transport, such as UDP, the NACK message is sent 202 back to the originator of the failed message at the port and IP 203 address from which the message was sent. Note that this may or may 204 not be the same port to which the appliation would typically receive 205 messages. 207 The behavior specified above is strictly necessary for any 208 generally useful form of a NACK mechanism. In the most general 209 case, when an implementation receives a message that it cannot 210 decompress, it has exactly three useful pieces of information: the 211 contents of the message, an indication of why the message cannot 212 be decoded, and the contents of the compressed message. Note that 213 none of these contain any indication of where the remote 214 applicaition is listening for messages, if it differs from the 215 sending port. 217 2.3 Receiving a SigComp NACK 219 The first action taken upon receipt of a NACK is an attempt to find 220 the message to which the NACK corresponds. This search is performed 221 using the 20-byte SHA-1 hash contained in the NACK. Once the 222 matching message is located, further operations are performed based 223 on the compartment that was associated with the sent message. 225 Further behavior of a node upon receiving a SigComp NACK depends on 226 whether a reliable or unreliable transport is being used. 228 2.3.1 Unreliable Transport 230 When SigComp is used over an unreliable transport, the application 231 has no reasonable expectation that the transport layer will deliver 232 any particular message. It then becomes the application layer's 233 responsibility to ensure that data is retransmitted as necessary. In 234 these circumstances, the NACK mechanism relies on such behavior to 235 ensure delivery of the message, and never performs retransmissions on 236 the application's behalf. 238 When a NACK is received for a message sent over an unreliable 239 transport, the NACK recipient uses the contained information to make 240 appropriate adjustments to the compressor associated with the proper 241 compartment. The exact nature of these adjustments are specific to 242 the compression scheme being used, and will vary from implementation 243 to implementation. The only requirement on these adjustments is that 244 they must have the effect of compensating for the error that has been 245 indicated (e.g. by removing the state that the remote node indicates 246 it cannot retreive). 248 In particular, when an unreliable transport is used, the original 249 message must not be retransmitted by the SigComp layer upon receipt 250 of a NACK. Instead, the next application initiated transmission of a 251 message will take advantage of the adjustments made as a result of 252 processing the NACK. 254 2.3.2 Reliable Transport 256 When a reliable transport is employed, the application makes a basic 257 assumption that any message passed down the stack will be 258 retransmitted as necessary to ensure that the remote node receives it 259 unless a failure is indicated by the transport layer. Because 260 SigComp acts as a shim between the transport-layer and the 261 application, it becomes the responsibility of the SigComp 262 implementation to ensure that any failure to transmit a message is 263 communicated to the application. 265 When a NACK is received for a message sent over a reliable transport, 266 the SigComp layer must indicate to the application that an error has 267 occured. In general, the application should react in the same way as 268 it does for any other transport layer error, such as a TCP connection 269 reset. For most applications, this reaction will initially be an 270 attempt to reestablish the connection, and re-initiate the failed 271 transaction. 273 2.4 Detecting Support for NACK 275 Detection of support for the NACK mechanism may be beneficial in some 276 certain circumstances. For example, with the current definition of 277 SigComp, acknowlegement of state receipt is required before a sender 278 can reference such state. In cases in which multiple messages are 279 sent before a response is received, the need to wait for such 280 responses can cause significant decreases in message compression 281 efficiency. If it is known that the receiver supports the NACK 282 mechanism, the sender can instead optimistically assume that the 283 state created by a sent message has been created, and is allowed to 284 be referenced; if such an assumption turns out to be false (due to, 285 for example, packet loss or packet reordering), the sender can 286 recover upon receipt of a NACK. 288 In order to facilitate such detection, implementations that will send 289 NACK messages upon decompression failure MUST set the least 290 significant bit of memory position 11 to "1" when initializing their 291 UDVMs. The bytecodes sent to such an endpoint can check whether this 292 bit is set, and send appropriate indication back to their compressor 293 as requested feedback. The other bits of bytes 10 and 11 are 294 reserved for future extensions and MUST be ignored for the purpose of 295 detection of NACK support. 297 Open Issue: Is the above behavior the best way to detect support? 298 Even without this additional behavior, it is trivial to probe for 299 NACK support by sending a message intentionally designed to fail 300 (e.g. message format 1 with random data for the state 301 identifier), and check whether a NACK is received in response. 302 The downside to such probing, of course, is that doing so adds 303 another round-trip of messages when communication is initiated. 304 Further, if a response to the probe is not received on an 305 unreliable transport, the endpoint performing the probe has no 306 clear way to determine whether the absence of a response is due to 307 lack of support by the remote endpoint, or due to packet loss. 308 Consequently, such a probe mechanism would require repeated 309 retransmissions if no response is received. 311 3. Message Format 313 SigComp NACK packets are syntactically valid SigComp messages which 314 have been specifically designed to be safely ignored by 315 implementations that do not support the NACK mechanism. 317 In particular, NACK messages are formatted as the second variant of a 318 SigComp message (typically used for code upload) with a "code_len" 319 field of zero. The NACK information (message identifier, reason for 320 failure, and error details) is encoded in the "remaining SigComp 321 message" area, typically used for input data. Further, the 322 "destination" field is used as a version identifier to indicate which 323 version of NACK is being employed. 325 3.1 Message Fields 327 Although the format of NACK messages are the same as the second 328 variant of normal SigComp messages, it is useful to demonstrate the 329 specific fields as they appear inside the "returned feedback item" 330 field. 332 --------------------------------------------------------------------- 334 0 1 2 3 4 5 6 7 335 +---+---+---+---+---+---+---+---+ 336 | 1 1 1 1 1 | T | 0 | 337 +---+---+---+---+---+---+---+---+ 338 | | 339 : returned feedback item : 340 | | 341 +---+---+---+---+---+---+---+---+ 342 | code_len = 0 | 343 +---+---+---+---+---+---+---+---+ 344 | code_len = 0 | version = 1 | 345 +---+---+---+---+---+---+---+---+ 346 | Reason Code | 347 +---+---+---+---+---+---+---+---+ 348 | | 349 : SHA-1 Hash of failed message : 350 | | 351 +---+---+---+---+---+---+---+---+ 352 | | 353 : Error Details : 354 | | 355 +---+---+---+---+---+---+---+---+ 357 Figure 1: SigComp NACK Message Format 359 --------------------------------------------------------------------- 361 o "Reason Code" is a one-byte value that indicates the nature of the 362 decompression failure. The specific codes are given in section 363 Section 3.2 365 o "SHA-1 Hash of failed message" contains the full 20-byte SHA-1 366 hash of the SigComp message that could not be decompressed. This 367 information allows the NACK recipient to locate the message that 368 failed to decompress so that adjustments to the correct 369 compartment can be performed. When performing this hash, the 370 entire SigComp message is used, from the header byte (binary 371 11111xxx) to the end of the input. Any lower-level protocol 372 headers (such as UDP or IP) and message delimiters (the 0xFFFF 373 that marks message boundaries in stream protocols) are not 374 included in the hash. When used over a stream based protocol, any 375 0xFFxx escape sequences are un-escaped before performing the hash 376 operation. 378 o "Error Details" provides any additional information that might be 379 useful in correcting the problem that caused decompression 380 failure. Its meaning is specific to the "Reason Code". See 381 section Section 3.2 for specific information on what appears in 382 this field. 384 o "Code_len" is the "code_len" field from a standard SigComp 385 message. It is always set to "0" for NACK messages. 387 o "Version" gives the version of the NACK mechanism being employed. 388 This document defines version 1. 390 3.2 Reason Codes 392 Note that many of the status codes are more useful in debugging 393 interoperability problems than with on-the-fly correction of errors. 394 The "STATE_NOT_FOUND" error is a notable exception: it will generally 395 cause the NACK receipient to encode future messages so as to not use 396 the indicated state. 398 Upon receiving the other status messages, an implementation would 399 typically be expected to either use a different set of bytecodes or, 400 if that is not an option, to send that specific message uncompressed. 402 --------------------------------------------------------------------- 404 Error Code Details 405 -------------------------- ---- --------------------------- 406 STATE_NOT_FOUND 1 State ID (6 - 20 bytes) 407 CYCLES_EXHAUSTED 2 Cycles Per Bit (1 byte) 408 USER_REQUESTED 3 409 SEGFAULT 4 410 TOO_MANY_STATE_REQUESTS 5 411 INVALID_STATE_ID_LENGTH 6 412 INVALID_STATE_PRIORITY 7 413 OUTPUT_OVERFLOW 8 414 STACK_UNDERFLOW 9 415 BAD_BITORDER 10 416 DIV_BY_ZERO 11 417 SWITCH_VALUE_TOO_HIGH 12 418 TOO_MANY_BITS_REQUESTED 13 419 INVALID_OPERAND 14 420 HUFFMAN_NO_MATCH 15 421 MESSAGE_TOO_SHORT 16 422 INVALID_CODE_LOCATION 17 423 BYTECODES_TOO_LARGE 18 Memory size (2 bytes) 424 INVALID_OPCODE 19 425 ID_TOO_SHORT 20 State ID (6 - 19 bytes) 426 ID_NOT_UNIQUE 21 State ID (6 - 20 bytes) 427 MULTILOAD_OVERWRITTEN 22 428 STATE_TOO_SHORT 23 State ID (6 - 20 bytes) 430 Only the six errors "STATE_NOT_FOUND", "CYCLES_EXHAUSTED", 431 "BYTECODES_TOO_LARGE", "ID_TOO_SHORT", "ID_NOT_UNIQUE", and 432 "STATE_TOO_SHORT" contain details; for all other error codes, the 433 "Error Details" field has zero length. 435 Figure 2: SigComp NACK Reason Codes 437 --------------------------------------------------------------------- 439 1. STATE_NOT_FOUND 440 A state that was referenced (either using STATE-ACCESS 441 instruction or in the actual SigComp message itself) cannot be 442 found. The "details" field contains the state identifier for 443 the state that could not be found. 445 2. CYCLES_EXHAUSTED 446 Decompression of the message has taken more cycles than were 447 allocated to it. The "details" field contains a one-byte value 448 that communicates the number of cycles per bit. The cycles per 449 bit is represented as an unsigned 8-bit integer (i.e. not 450 encoded). 452 3. USER_REQUESTED 453 The DECOMPRESSON-FAILURE opcode has been executed. 455 4. SEGFAULT 456 An attempt to read from or write to memory that is outside of 457 the UDVM's memory space has been attempted. 459 5. TOO_MANY_STATE_REQUESTS 460 More than four requests to store or delete state objects have 461 been requested. 463 6. INVALID_STATE_ID_LENGTH 464 A state id length less than 6 or greater than 20 has been 465 specified. 467 7. INVALID_STATE_PRIORITY 468 A state priority of 65535 has been specified when attempting to 469 store a state. 471 8. OUTPUT_OVERFLOW 472 The decompressed message is too large to be decoded by the 473 receiving node. 475 9. STACK_UNDERFLOW 476 An attempt to pop a value off the UDVM stack was made with a 477 stack_fill value of 0. 479 10. BAD_BITORDER 480 An INPUT-BITS or INPUT-HUFFMAN instruction was encountered with 481 the "input_bit_order" register set to an invalid value (i.e. 482 one of the upper five bits is set). 484 11. DIV_BY_ZERO 485 A DIVIDE or REMAINDER opcode was encountered with a divisor of 486 0. 488 12. SWITCH_VALUE_TOO_HIGH 489 The input to a SWITCH opcode exceeds the number of branches 490 defined. 492 13. TOO_MANY_BITS_REQUESTED 493 An INPUT instruction was encountered that attempted to input 494 more than 16 bits. 496 14. INVALID_OPERAND 497 An operand for an instruction could not be resolved to an 498 integer value (e.g. a literal or reference operand beginning 499 with 11111111). 501 15. HUFFMAN_NO_MATCH 502 The input string does not match any of the bitcodes in the 503 INPUT-HUFFMAN opcode. 505 16. MESSAGE_TOO_SHORT 506 When attempting to decode a SigComp message, the recipient 507 determined that there were not enough bytes in the message for 508 it to be valid. 510 17. INVALID_CODE_LOCATION 511 The "code location" field in the SigComp message was set to the 512 invalid value of 0. 514 18. BYTECODES_TOO_LARGE 515 The bytecodes that a SigComp message attempted to upload exceed 516 the amount of memory available in the receiving UDVM. The 517 details field is a two-byte expression of the 518 DECOMPRESSION_MEMORY_SIZE of the receiving UDVM. This value is 519 communicated most-significant-byte first. 521 19. INVALID_OPCODE 522 The UDVM attempted to identify an undefined byte value as an 523 instruction. 525 20. ID_NOT_UNIQUE 526 A partial state identifier that was used to access state matched 527 more than one state item. 529 21. ID_TOO_SHORT 530 A unique state item was matched but fewer bytes of state ID were 531 sent than required by the minimum_access_length. 533 22. MULTILOAD_OVERWRITTEN 534 A MULTILOAD instruction attempted to overwrite itself. 536 23. STATE_TOO_SHORT 537 A STATE-ACCESS instruction has attempted to copy more bytes from 538 a state item than the state item actually contains. 540 4. Security Considerations 542 4.1 Reflector Attacks 544 Because SigComp NACK messages trigger responses, it is possible to 545 trigger them by intentionally sending malformed messages to a SigComp 546 implementation with a spoofed IP address. However, because such 547 actions can only generate one message for each message sent, they 548 don't serve as amplifier attacks. Futher, due to the reasonably 549 small size of NACK packets, there cannot be a significant increase in 550 the size of the packet generated. 552 It is worth noting that nearly all deployed protocols exhibit this 553 same behavior. 555 4.2 NACK Spoofing 557 Although it is possible to forge NACK message as if they were 558 generated by a different node, the damage that can be caused is 559 minimal. Reporting a loss of state will typically result in nothing 560 more than the re-transmission of that state in a subsequent message. 561 Other failure codes would result in the next message being sent using 562 an alternate compression mechanism, or possibly uncompressed. 564 Although all of the above consequences result in slightly larger 565 messages, none of them have particularly catastrophic implications 566 for security. 568 Normative References 570 [1] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z. 571 and J. Rosenberg, "Signaling Compression", RFC 3320, January 572 2003. 574 [2] Hannu, H., Christoffersson, J., Forsgren, S., Leung, K., Liu, Z. 575 and R. Price, "Signalling Compression (SigComp) - Extended 576 Operations", RFC 3321, January 2003. 578 Non-Normative References 580 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 581 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 582 Session Initiation Protocol", RFC 3261, June 2002. 584 Author's Address 586 Adam Roach 587 dynamicsoft 588 5100 Tennyson Pkwy 589 Suite 1200 590 Plano, TX 75024 591 US 593 EMail: adam@dynamicsoft.com 595 Appendix A. Comments and Feedback 597 Editorial comments should be directed to the author at 598 adam@dynamicsoft.com. Discussion of the mechanism described in this 599 document should be directed to the ROHC mailing list (rohc@ietf.org). 601 Appendix B. Changes 603 o Moved NACK parameters to end of message, so that NACK messages cen 604 be distinguished from standalone feedback messages 606 o Changed behavior of endpoint receiving a NACK for a message sent 607 on a reliable transport. 609 o Clarified some of the motivating text relating to server failover 611 o Added mechanism for detection of NACK support 613 Full Copyright Statement 615 Copyright (C) The Internet Society (2002). All Rights Reserved. 617 This document and translations of it may be copied and furnished to 618 others, and derivative works that comment on or otherwise explain it 619 or assist in its implementation may be prepared, copied, published 620 and distributed, in whole or in part, without restriction of any 621 kind, provided that the above copyright notice and this paragraph are 622 included on all such copies and derivative works. However, this 623 document itself may not be modified in any way, such as by removing 624 the copyright notice or references to the Internet Society or other 625 Internet organizations, except as needed for the purpose of 626 developing Internet standards in which case the procedures for 627 copyrights defined in the Internet Standards process must be 628 followed, or as required to translate it into languages other than 629 English. 631 The limited permissions granted above are perpetual and will not be 632 revoked by the Internet Society or its successors or assigns. 634 This document and the information contained herein is provided on an 635 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 636 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 637 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 638 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 639 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 641 Acknowledgement 643 Funding for the RFC Editor function is currently provided by the 644 Internet Society.