doc: Add RFC documents

1 files changed, 1571 insertions, 0 deletions

diff --git a/doc/rfc/rfc4896.txt b/doc/rfc/rfc4896.txt
new file mode 100644
index 0000000..7ed2505
--- /dev/null
+++ b/doc/rfc/rfc4896.txt
@@ -0,0 +1,1571 @@
+
+
+
+
+
+
+Network Working Group                                         A. Surtees
+Request for Comments: 4896                                       M. West
+Updates: 3320, 3321, 3485                    Siemens/Roke Manor Research
+Category: Standards Track                                     A.B. Roach
+                                                        Estacado Systems
+                                                               June 2007
+
+
+     Signaling Compression (SigComp) Corrections and Clarifications
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   This document describes common misinterpretations and some
+   ambiguities in the Signaling Compression Protocol (SigComp), and
+   offers guidance to developers to resolve any resultant problems.
+   SigComp defines a scheme for compressing messages generated by
+   application protocols such as the Session Initiation Protocol (SIP).
+   This document updates the following RFCs: RFC 3320, RFC 3321, and RFC
+   3485.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Surtees, et al.             Standards Track                     [Page 1]
+
+RFC 4896         SigComp Corrections and Clarifications        June 2007
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Decompression Memory Size  . . . . . . . . . . . . . . . . . .  3
+     2.1.  Bytecode within Decompression Memory Size  . . . . . . . .  3
+     2.2.  Default Decompression Memory Size  . . . . . . . . . . . .  4
+   3.  UDVM Instructions  . . . . . . . . . . . . . . . . . . . . . .  5
+     3.1.  Data Input Instructions  . . . . . . . . . . . . . . . . .  5
+     3.2.  MULTILOAD  . . . . . . . . . . . . . . . . . . . . . . . .  5
+     3.3.  STATE-FREE . . . . . . . . . . . . . . . . . . . . . . . .  6
+     3.4.  Using the Stack  . . . . . . . . . . . . . . . . . . . . .  6
+   4.  Byte Copying Rules . . . . . . . . . . . . . . . . . . . . . .  7
+     4.1.  Instructions That Use Byte Copying Rules . . . . . . . . .  9
+   5.  State Retention Priority . . . . . . . . . . . . . . . . . . .  9
+     5.1.  Priority Values  . . . . . . . . . . . . . . . . . . . . .  9
+     5.2.  Multiple State Retention Priorities  . . . . . . . . . . . 10
+     5.3.  Retention Priority 65535 (or -1) . . . . . . . . . . . . . 10
+   6.  Duplicate State  . . . . . . . . . . . . . . . . . . . . . . . 14
+   7.  State Identifier Clashes . . . . . . . . . . . . . . . . . . . 14
+   8.  Message Misordering  . . . . . . . . . . . . . . . . . . . . . 15
+   9.  Requested Feedback . . . . . . . . . . . . . . . . . . . . . . 15
+     9.1.  Feedback When SMS Is Zero  . . . . . . . . . . . . . . . . 15
+     9.2.  Updating Feedback Requests . . . . . . . . . . . . . . . . 16
+   10. Advertising Resources  . . . . . . . . . . . . . . . . . . . . 16
+     10.1. The I-bit and Local State Items  . . . . . . . . . . . . . 16
+     10.2. Dynamic Update of Resources  . . . . . . . . . . . . . . . 17
+     10.3. Advertisement of Locally Available State Items . . . . . . 17
+       10.3.1.  Basic SigComp . . . . . . . . . . . . . . . . . . . . 18
+       10.3.2.  Dictionaries  . . . . . . . . . . . . . . . . . . . . 18
+       10.3.3.  SigComp Extended Mechanisms . . . . . . . . . . . . . 19
+   11. Uncompressed Bytecode  . . . . . . . . . . . . . . . . . . . . 19
+   12. RFC 3485 SIP/SDP Static Dictionary . . . . . . . . . . . . . . 20
+   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 21
+   14. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
+   15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
+   16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
+     16.1. Normative References . . . . . . . . . . . . . . . . . . . 23
+     16.2. Informative References . . . . . . . . . . . . . . . . . . 23
+   Appendix A.  Dummy Application Protocol (DAP)  . . . . . . . . . . 24
+     A.1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . 24
+     A.2.  Processing a DAP Message . . . . . . . . . . . . . . . . . 24
+     A.3.  DAP Message Format in ABNF . . . . . . . . . . . . . . . . 26
+     A.4.  An Example of a DAP Message  . . . . . . . . . . . . . . . 26
+
+
+
+
+
+
+
+Surtees, et al.             Standards Track                     [Page 2]
+
+RFC 4896         SigComp Corrections and Clarifications        June 2007
+
+
+1.  Introduction
+
+   SigComp [1] defines the Universal Decompressor Virtual Machine (UDVM)
+   for decompressing messages sent by a compliant compressor.  SigComp
+   further describes mechanisms to deal with state handling, message
+   structure, and other details.  While the behavior of the decompressor
+   is specified in great detail, the behavior of the compressor is left
+   as a choice for the implementer.  During implementation and
+   interoperability tests, some areas of SigComp that need clarification
+   have been identified.  The sections that follow enumerate the problem
+   areas identified in the specification, and attempt to provide
+   clarification.
+
+   Note that, as this document refers to sections in several other
+   documents, the following notation is applied:
+
+      "in Section 3.4" refers to Section 3.4 of this document
+      "in RFC 3320-Section 3.4" refers to Section 3.4 of RFC 3320 [1]
+
+1.1.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [5].
+
+2.  Decompression Memory Size
+
+2.1.  Bytecode within Decompression Memory Size
+
+   SigComp [1] states that the default Decompression Memory Size (DMS)
+   is 2K.  The UDVM memory size is defined in RFC 3320-Section 7 to be
+   (DMS - n), where n is the size of the SigComp message, for messages
+   transported over UDP and (DMS / 2) for those transported over TCP.
+   This means that when the message contains the bytecode (as it will
+   for at least the first message) there will actually be two copies of
+   the bytecode within the decompressor memory (see Figure 1).  The
+   presence of the second copy of bytecode in decompressor memory is
+   correct in this case.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Surtees, et al.             Standards Track                     [Page 3]
+
+RFC 4896         SigComp Corrections and Clarifications        June 2007
+
+
+    |<----------------------------DMS--------------------------------->|
+    |<-----SigComp message---->|<------------UDVM memory size--------->|
+    +-+----------+-------------+-----+----------+----------------------+
+    | | bytecode |  comp msg   |     | bytecode | circular buffer      |
+    +-+----------+-------------+-----+----------+----------------------+
+     ^                            ^
+     |                            |
+    SigComp header          Low bytes of UDVM
+
+            Figure 1: Bytecode and UDVM memory size within DMS
+
+2.2.  Default Decompression Memory Size
+
+   For many implementations, the length of decompression bytecode sent
+   is in the range of three to four hundred bytes.  Because SigComp
+   specifies a default DMS of 2K, the described scheme seriously
+   restricts the size of the circular buffer, and of the compressed
+   message itself.  In some cases, this set of circumstances has a
+   damaging effect on the compression ratio; for others, it makes it
+   completely impossible to send certain messages compressed.
+
+   To address this problem, those mandating the use of SigComp need to
+   also provide further specification for their application that
+   mandates the use of an appropriately sized DMS.  Sizing of such a DMS
+   should take into account (1) the size of bytecode for algorithms
+   likely to be employed in compressing the application messages, (2)
+   the size of any buffers or structures necessary to execute such
+   algorithms, (3) the size of application messages, and (4) the average
+   entropy present within a single application message.
+
+   For example, assume a typical compression algorithm requiring
+   approximately 400 bytes of bytecode, plus about 2432 bytes of data
+   structures.  The required UDVM memory size is 400 + 2432 = 2832.  For
+   a TCP-based protocol, this means the DMS must be at least 5664 (2832
+   * 2) bytes, which is rounded up to 8k.  For a UDP-based protocol, one
+   must take into account the size of the SigComp messages themselves.
+   Assuming a text-based protocol with sufficient average entropy to
+   compress a single message by 50% (without any previous message
+   history), and messages that are not expected to exceed 8192 bytes in
+   size, the protocol message itself will add 4096 bytes to the SigComp
+   message size (on top of the 400 bytes of bytecode plus a 3-byte
+   header), or 4096 + 400 + 3 = 4499.  To calculate the DMS, one must
+   add this to the required UDVM memory size: 2832 + 4499 = 6531, which
+   is again rounded up to 8k of DMS.
+
+
+
+
+
+
+
+Surtees, et al.             Standards Track                     [Page 4]
+
+RFC 4896         SigComp Corrections and Clarifications        June 2007
+
+
+3.  UDVM Instructions
+
+3.1.  Data Input Instructions
+
+   When inputting data from the compressed message, the INPUT-BYTES (RFC
+   3320-Section 9.4.2) and INPUT-BITS (RFC 3320-Section 9.4.3)
+   instructions both have the paragraph:
+
+   "If the instruction requests data that lies beyond the end of the
+   SigComp message, no data is returned.  Instead the UDVM moves program
+   execution to the address specified by the address operand."
+
+   The intent is that if n bytes/bits are requested, but only m are left
+   in the message (where m < n), then the decompression dispatcher MUST
+   NOT return any bytes/bits to the UDVM, and the m bytes/bits that are
+   there MUST remain in the message unchanged.
+
+   For example, if the remaining bytes of a message are: 0x01 0x02 0x03
+   and the UDVM encounters an INPUT-BYTES (6, a, b) instruction.  Then
+   the decompressor dispatcher returns no bytes and jumps to the
+   instruction specified by b.  This contains an INPUT-BYTES (2, c, d)
+   instruction so the decompressor dispatcher successfully returns the
+   bytes 0x01 and 0x02.
+
+   In the case where an INPUT-BYTES instruction follows an INPUT-BITS
+   instruction that has left a partial byte in the message, the partial
+   byte should still be thrown away even if there are not enough bytes
+   to input.
+
+   INPUT-BYTES (0, a, b) can be used to flush out a partial byte.
+
+3.2.  MULTILOAD
+
+   In order to make step-by-step implementation simpler, the MULTILOAD
+   instruction is explicitly not allowed to write into any memory
+   positions occupied by the MULTILOAD opcode or any of its parameters.
+   Additionally, if there is any indirection of parameters, the
+   indirection MUST be done at execution time.
+
+   Any implementation technique other than a step-by-step implementation
+   (e.g., decode all operands then execute, which is the model of all
+   other instructions) MUST yield the same result as a step-by-step
+   implementation would.
+
+
+
+
+
+
+
+
+Surtees, et al.             Standards Track                     [Page 5]
+
+RFC 4896         SigComp Corrections and Clarifications        June 2007
+
+
+   For example:
+
+   at (64)
+
+   :location_a                     pad (2)
+   :location_b                     pad (2)
+   :location_c                     pad (2)
+   pad (30)
+   :udvm_memory_size               pad (2)
+   :circular_buffer                pad (2)
+
+   align (64)
+
+   MULTILOAD (location_a, 3, circular_buffer,
+                   udvm_memory_size, $location_a)
+
+   The step-by-step implementation would: write the address of
+   circular_buffer into location_a (memory address 64); write the
+   address of udvm_memory_size into location_a + 2 (memory address 66);
+   write the value stored in location_a (accessed using indirection -
+   that is now the address of circular_buffer) into location_a + 4
+   (memory address 68).  Therefore, at the end of the execution by a
+   correct implementation, location_c will contain the address of
+   circular_buffer.
+
+3.3.  STATE-FREE
+
+   The STATE-FREE instruction does not check the minimum_access_length.
+   This is correct because the state cannot be freed until the
+   application has authenticated the message.  The lack of checking does
+   not pose a security risk because if the sender has enough information
+   to create authenticated messages, then sending messages that save
+   state can push previous state out of storage anyway.
+
+   The STATE-FREE instruction can only free state in the compartment
+   that corresponds to the message being decompressed.  Attempting to
+   free state that is either from another compartment, or that is not
+   associated with any compartment, has no effect.
+
+3.4.  Using the Stack
+
+   The instructions PUSH, POP, CALL, and RETURN make use of a stack that
+   is set up using the well-known memory address stack_location to
+   define where in memory the stack is located.  Use of the stack is
+   defined in RFC 3320-Section 8.3, which states: '"Pushing" a value on
+   the stack is an abbreviation for copying the value to
+
+
+
+
+
+Surtees, et al.             Standards Track                     [Page 6]
+
+RFC 4896         SigComp Corrections and Clarifications        June 2007
+
+
+   stack[stack_fill] and then increasing stack_fill by 1.' and
+   'stack_fill is an abbreviation for the 2-byte word at stack_location
+   and stack_location + 1'.
+
+   In the very rare case that the value of stack_fill is 0xFFFF when a
+   value is pushed onto the stack, then the original stack_fill value
+   MUST be increased by 1 to 0x0000 and written back to stack_location
+   and stack_location + 1 (which will overwrite the value that has been
+   pushed onto the stack).
+
+      The new value pushed onto the stack has, in theory, been written
+      to stack [0xFFFF] = stack_location.  Stack_fill would then be
+      increased by 1; however, the value at stack_location and
+      stack_location + 1 has just been updated.  To maintain the
+      integrity of the stack with regard to over and underflow,
+      stack_fill cannot be re-read at this point, and the pushed value
+      is overwritten.
+
+4.  Byte Copying Rules
+
+   RFC 3320-Section 8.4 states that "The string of bytes is copied in
+   ascending order of memory address, respecting the bounds set by
+   byte_copy_left and byte_copy_right."  This is misleading in that it
+   is perfectly legitimate to copy bytes outside of the bounds set by
+   byte_copy_left and byte_copy_right.  Byte_copy_left and
+   byte_copy_right provide the ability to maintain a circular buffer as
+   follows:
+
+   For moving to the right
+
+   if current_byte == ((byte_copy_right - 1) mod 2 ^ 16):
+       next_byte = byte_copy_left
+   else:
+       next_byte = (current_byte + 1) mod 2 ^ 16
+
+   which is equivalent to the algorithm given in RFC 3320-Section 8.4.
+
+   For moving to the left
+
+   if current_byte == byte_copy_left:
+       previous_byte = (byte_copy_right - 1) mod 2 ^ 16
+   else:
+       previous_byte = (current_byte - 1) mod 2 ^ 16
+
+   Moving to the left is only used for COPY_OFFSET.
+
+   Consequently, copying could begin to the left of byte_copy_left and
+   continue across it (and jump back to it according to the given
+
+
+
+Surtees, et al.             Standards Track                     [Page 7]
+
+RFC 4896         SigComp Corrections and Clarifications        June 2007
+
+
+   algorithm if necessary) and could begin at or to the right of
+   byte_copy_right (though care must be taken to prevent decompression
+   failure due to writing to / reading from beyond the UDVM memory).
+
+   For further clarity: consider the UDVM memory laid out as follows,
+   with byte_copy_left and byte_copy_right in the locations indicated by
+   "BCL" and "BCR", respectively:
+
+   +----------------------------------------+
+   |                                        |
+   +----------^------------^----------------+
+             BCL          BCR
+
+   If an opcode read or wrote bytes starting to the left of
+   byte_copy_left, it would do so in the following order:
+
+   +----------------------------------------+
+   |       abcdefghijkl                     |
+   +----------^------------^----------------+
+             BCL          BCR
+
+   If the opcode continues to read or write until it reaches
+   byte_copy_right, it would then wrap around to byte_copy_left and
+   continue (letters after the wrap are capitalized for clarity):
+
+   +----------------------------------------+
+   |       abcQRSTUVjklmnop                 |
+   +----------^------------^----------------+
+             BCL          BCR
+
+   Similarly, writing to the right of byte_copy_right is a perfectly
+   valid operation for opcodes that honor byte copying rules:
+
+   +----------------------------------------+
+   |                          abcdefg       |
+   +----------^------------^----------------+
+             BCL          BCR
+
+   A final, somewhat odd relic of the foregoing rules occurs when
+   byte_copy_right is actually less than byte_copy_left.  In this case,
+   reads and writes will skip the memory between the pointers:
+
+   +----------------------------------------+
+   |     abcde             fghijkl          |
+   +----------^------------^----------------+
+             BCR          BCL
+
+
+
+
+
+Surtees, et al.             Standards Track                     [Page 8]
+
+RFC 4896         SigComp Corrections and Clarifications        June 2007
+
+
+4.1.  Instructions That Use Byte Copying Rules
+
+   This document amends the list of instructions that obey byte copying
+   rules in RFC 3320-Section 8.4 to include STATE-CREATE and CRC.
+
+   RFC 3320-Section 8.4 specifies the byte copying rules and includes a
+   list of the instructions that obey them.  STATE-CREATE is not in this
+   list but END-MESSAGE is.  This caused confusion due to the fact that
+   neither instruction actually does any byte copying; rather, both
+   instructions give information to the state-handler to create state.
+   Logically, both instructions should have the same information about
+   byte copying.
+
+   When state is created by the state-handler (whether from an END-
+   MESSAGE or a STATE-CREATE instruction), the byte copying rules of RFC
+   3320-Section 8.4 apply.
+
+   Note that, if the contents of the UDVM changes between the occurrence
+   of the STATE-CREATE instruction and the state being created, the
+   bytes that are stored are those in the buffer at the time of creation
+   (i.e., when the message has been decompressed and authenticated).
+
+   CRC is not mentioned in RFC 3320-Section 8.4 in the list of
+   instructions that obey byte copying rules, but its description in RFC
+   3320-Section 9.3.5 states that these rules are to be obeyed.  When
+   reading data over which to perform the CRC check, byte copying rules
+   apply as specified in RFC 3320-Section 8.4.
+
+   When the partial identifier for a STATE-FREE instruction is read,
+   (during the execution of END-MESSAGE) byte copying rules as per RFC
+   3320-Section 8.4 apply.
+
+   Given that reading the buffer for creating and freeing state within
+   the END-MESSAGE instruction obeys byte copying rules, there may be
+   some confusion as to whether reading feedback items should also obey
+   byte copying rules.  Byte copying rules do not apply for reading
+   feedback items.
+
+5.  State Retention Priority
+
+5.1.  Priority Values
+
+   For state_retention_priority, 65535 < 0 < 1 < ... < 65534.  This is
+   slightly counter intuitive, but is correct.
+
+
+
+
+
+
+
+Surtees, et al.             Standards Track                     [Page 9]
+
+RFC 4896         SigComp Corrections and Clarifications        June 2007
+
+
+5.2.  Multiple State Retention Priorities
+
+   There may be confusion when the same piece of state is created at two
+   different retention priorities.  The following clarifies this:
+
+      The retention priority MUST be associated with the compartment and
+      not with the piece of state.  For example, if endpoint A creates a
+      piece of state with retention priority 1 and endpoint B creates
+      exactly the same state with retention priority 2, there should be
+      one copy (assuming the model of state management suggested in
+      SigComp [1]) of the actual state, but each compartment should keep
+      a record of this piece of state with its own priority.  (If this
+      does not happen then the state could be kept for longer than A
+      anticipated or less time than B anticipated, depending on which
+      priority is used.  This could cause Decompression Failure to
+      occur.)
+
+      If the same piece of state is created within a compartment with a
+      different priority, then one copy of it should be stored with the
+      new priority and it MUST count only once against SMS.  That is,
+      the state creation updates the priority rather than creates a new
+      piece of state.
+
+5.3.  Retention Priority 65535 (or -1)
+
+   There is potentially a problem with storing multiple pieces of state
+   with the minimum retention priority (65535) as defined in SigComp
+   [1].  This can be shown by considering the following examples that
+   are of shared mode, which is documented in SigComp Extended [2].  The
+   key thing about state with retention priority 65535 is that it can be
+   created by an endpoint in the decompressor compartment without the
+   knowledge of the remote compressor (which controls state creation in
+   the decompressor compartment).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Surtees, et al.             Standards Track                    [Page 10]
+
+RFC 4896         SigComp Corrections and Clarifications        June 2007
+
+
+   Example 1:
+
+       [SMn state is shared mode state (priority 65535),
+        BC is bytecode state (priority 1),
+        BFn is buffer state (priority 0)]
+
+       Endpoint A                  Endpoint B
+       [decomp cpt]                [comp cpt]
+
+       [SM1]
+       ------------------------------->
+                                   [SM1]
+
+       [SM1, SM2]
+       --------------------X (message lost)
+
+                                   [SM1, BC, BF1]
+       <------------ref SM1------------
+       [SM2, BC, BF1]
+                                   endpoint B still believes SM1
+                                   is at endpoint A
+
+                                   [BC, BF1, BF2]
+       <------------ref SM1------------
+
+       decompression failure at A
+       because SM1 has already been deleted
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Surtees, et al.             Standards Track                    [Page 11]
+
+RFC 4896         SigComp Corrections and Clarifications        June 2007
+
+
+   Example 2:
+
+       Endpoint A                  Endpoint B
+       [decomp cpt]                [comp cpt]
+
+       [SM1]
+       ------------------------------->
+                                   [SM1]
+
+                                   [SM1, BC, BF1]
+       (message lost)X------ref SM1-----
+
+       [SM1, SM2]
+       ------------------------------->
+                                   endpoint B does not create SM2
+                                   because there is no space
+                                   [SM1, BC, BF1]
+
+                                   [SM1, BC, BF1, BF2]
+       <------------ref SM1------------
+       [SM2, BC, BF2]
+                                   endpoint B still believes SM1
+                                   is at endpoint A
+
+                                   [BC, BF1, BF2, BF3]
+       <------------ref SM1------------
+
+       decompression failure at A
+       because SM1 has already been deleted
+
+                Figure 2: Retention priority 65535 examples
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Surtees, et al.             Standards Track                    [Page 12]
+
+RFC 4896         SigComp Corrections and Clarifications        June 2007
+
+
+   Once there is more than one piece of minimum priority state created
+   in a decompressor compartment, the corresponding compressor cannot be
+   certain about which pieces of state are present in that
+   (decompressor) compartment.  If there is only one piece of state,
+   then no such ambiguity exists.
+
+   The problem is a consequence of the different rules for the creation
+   of minimum priority state.  In particular, the creation of the second
+   piece of state without the knowledge of the compressor could mean
+   that the first piece is pushed out earlier than the compressor
+   expects (despite the fact that the state processing rules from
+   SigComp [1] are being implemented correctly).
+
+   SigComp [1] also states that a compressor MUST be certain that all of
+   the data needed to decompress a SigComp message is available at the
+   receiving endpoint.  Thus, it SHOULD NOT reference any state unless
+   it can be sure that the state exists.  The fact that the compressor
+   at B has no way of knowing how much state has been created at A can
+   lead to a loss of synchronization between the endpoints, which is not
+   acceptable.
+
+   One observation is that it is always safe to reference a piece of
+   minimum priority state following receipt of the advertisement of the
+   state.
+
+   If it is known that both endpoints are running SigComp version 2, as
+   defined in NACK [3], then an endpoint MAY assume that the likelihood
+   of a loss of synchronization is very small, and rely on the NACK
+   mechanism for recovery.
+
+   However, for a compressor to try and avoid causing the generation of
+   NACKs, it has to be able to make some assumptions about the behavior
+   of the peer compressor.  Also, if one of the endpoints does not
+   support NACK, then some other solution is needed.
+
+   Consequently, where NACK is not supported or for NACK averse
+   compressors, the recommendation is that only one piece of minimum
+   priority state SHOULD be present in a compartment at any one time.
+   If both endpoints support NACK [3], then this recommendation MAY be
+   relaxed, but implementers need to think carefully about the
+   consequences of creating multiple pieces of minimum priority state.
+   In either case, if the behavior of the application restricts the
+   message flow, this fact could be exploited to allow safe creation of
+   multiple minimum priority states; however, care must still be taken.
+
+   Note that if a compressor wishes the remote endpoint to be able to
+   create a new piece of minimum priority state, it can use the STATE-
+   FREE instruction to remove the existing piece of state.
+
+
+
+Surtees, et al.             Standards Track                    [Page 13]
+
+RFC 4896         SigComp Corrections and Clarifications        June 2007
+
+
+6.  Duplicate State
+
+   If a piece of state is created in a compartment in which it already
+   exists, the time of its creation SHOULD be updated as if it had just
+   been created, irrespective of whether or not there is a new state
+   retention priority.
+
+7.  State Identifier Clashes
+
+   RFC 3320-Section 6.2 states that when creating a piece of state, the
+   full 20-byte hash should be checked to see whether or not another
+   piece of state with this identifier exists.  If it does, and the
+   state item is not identical, then the new creation MUST fail.  It is
+   stated that the probability of this occurring is vanishingly small
+   (and so it is, see below).
+
+   However, when state is accessed, only the first n bytes of the state
+   identifier are used, where n could be as low as 6.  At this point, if
+   there are two pieces of state with the same first n bytes of state
+   identifier, the STATE-ACCESS instruction will cause decompression
+   failure.  The compressor referencing the state will not expect this
+   failure mode because the state creation succeeded without a clash.
+   At a server endpoint where there could be thousands or millions of
+   pieces of state, how likely is this to actually happen?
+
+   Consider the birthday paradox (where there only have to be 23 people
+   in a room to have a greater than 50% chance that two of them will
+   have the same birthday (Birthday [8])).
+
+   The naive calculation using factorials gives:
+
+                      N!
+   Pd(N,s) = 1 - -------------
+                 (N - s)! N^s
+
+   where N is the number of possible values and s is the sample size.
+
+   However, due to dealing with large numbers, an approximation is
+   needed:
+
+   Pd(N,s) = 1 - e^( LnFact(N) - LnFact(N-s) - s Ln(N) )
+
+   where LnFact (x) is the log of x!, which can be approximated by:
+
+
+
+
+
+
+
+
+Surtees, et al.             Standards Track                    [Page 14]
+
+RFC 4896         SigComp Corrections and Clarifications        June 2007
+
+
+   LnFact(x) ~ (x + 1/2) Ln(x) - x + Ln(2*Pi)/2 +
+
+                1       1         1           1
+               --- - ------- + -------- - --------
+               12x   360 x^3   1260 x^5   1680 x^7
+
+   which using N = 2^48 [6 octet partial state identifier] gives:
+
+   s = 1 000 000: Pd (N,s) = 0.018%
+   s = 10 000 000: Pd (N,s) = 16.28%
+   s = 100 000 000: Pd (N,s) = 100.00%
+
+   so when implementing, thought should be given as to whether or not 6
+   octets of state identifier is enough to ensure that state access will
+   be successful (particularly at a server).
+
+   The likelihood of a clash when using the full 20 octets of state
+   identifier, does indeed have a vanishingly small probability:
+   using N = 2^160 [full 20 octet state identifier] gives:
+
+   s = 1 000 000: Pd (N,s) = 3.42E-35%
+   s = 10 000 000: Pd (N,s) = 3.42E-33%
+   s = 100 000 000: Pd (N,s) = 3.42E-31%
+
+   Consequently, care must be taken when deciding how many octets of
+   state identifier to use to access state at the server.
+
+8.  Message Misordering
+
+   SigComp [1] makes only one reference to the possibility of misordered
+   messages.  However, the statement that the 'compressor MUST ensure
+   that the message can be decompressed using the resources available at
+   the remote endpoint' puts the onus on the compressor to take account
+   of the possibility of misordering occurring.
+
+   Whether misordering can occur and whether that would have an impact
+   depends on the compartment definition and the transport protocol in
+   use.  Therefore, it is up to the implementer of the compressor to
+   take these factors into account.
+
+9.  Requested Feedback
+
+9.1.  Feedback When SMS Is Zero
+
+   If an endpoint receives a request for feedback, then it SHOULD return
+   the feedback even if its SMS is zero.  The storage overhead of the
+   requested feedback is NOT part of the SMS.
+
+
+
+
+Surtees, et al.             Standards Track                    [Page 15]
+
+RFC 4896         SigComp Corrections and Clarifications        June 2007
+
+
+9.2.  Updating Feedback Requests
+
+   When an endpoint receives a valid message it updates the requested
+   feedback data for that compartment.  RFC 3320-Section 5 states that
+   there is no need to transmit any requested feedback item more than
+   once.  However, there are cases where it would be beneficial for the
+   feedback to be sent more than once (e.g., a retransmitted 200 OK SIP
+   message [9] to an INVITE SIP message implies that the original 200
+   OK, and the feedback it carried, might not have reached the remote
+   endpoint).  Therefore, an endpoint SHOULD transmit feedback
+   repeatedly until it receives another valid message that updates the
+   feedback.
+
+   RFC 3320-Section 9.4.9 states that when requested_feedback_location
+   equals zero, no feedback request is made.  However, there is no
+   indication of whether this means that the existing feedback data is
+   left untouched or if this means that the existing feedback data
+   SHOULD be overwritten to be 'no feedback data'.  If
+   requested_feedback_location equals zero, the existing feedback data
+   SHOULD be left untouched and returned in any subsequent messages as
+   before.
+
+   RFC 3320-Section 9.4.9 also makes no statement about what happens to
+   existing feedback data when requested_feedback_location does not
+   equal zero but the Q flag indicating the presence/absence of a
+   requested_feedback_item is zero.  In this case, the existing feedback
+   data SHOULD be overwritten to be 'no feedback data'.
+
+10.  Advertising Resources
+
+10.1.  The I-bit and Local State Items
+
+   The I-bit in requested feedback is a mechanism by which a compressor
+   can tell a remote endpoint that it is not going to access any local
+   state items.  By doing so, it gives the remote endpoint the option of
+   not advertising them in subsequent messages.  Setting the I-bit does
+   not obligate the remote endpoint to cease sending advertisements.
+
+   The remote endpoint SHOULD still advertise its parameters such as DMS
+   and state memory size (SMS).  (This is particularly important; if the
+   sender of the first message sets the I-bit, it will still want the
+   advertisement of parameters from the receiver.  If it doesn't receive
+   these, it has to assume the default parameters which will affect
+   compression efficiency.)
+
+   The endpoint receiving an I-bit of 1 can reclaim the memory used to
+   store the locally available state items.  However, this has NO impact
+
+
+
+
+Surtees, et al.             Standards Track                    [Page 16]
+
+RFC 4896         SigComp Corrections and Clarifications        June 2007
+
+
+   on any state that has been created by the sender using END-MESSAGE or
+   STATE-CREATE instructions.
+
+10.2.  Dynamic Update of Resources
+
+   Decompressor resources such as SMS and DMS can be dynamically updated
+   at the compressor by use of the SMS and DMS bits in returned
+   parameters feedback (see RFC 3320-Section 9.4.9).  Changing resources
+   dynamically (apart from initial advertisements for each compartment)
+   is not expected to happen very often.
+
+   If additional resources are advertised to a compressor, then it is up
+   to the implementation at the compressor whether or not to make use of
+   these resources.  For example, if the decompressor advertises 8k SMS
+   but the compressor only has 4k SMS, then the compressor MAY choose
+   not to use the extra 4k (e.g., in order to monitor state saved at the
+   decompressor).  In this case, there is no synchronization problem.
+   The compressor MUST NOT use more than the most recently advertised
+   resources.  Note that the compressor SMS is unofficial (it enables
+   the compressor to monitor decompressor state) and is separate from
+   the SMS advertised by the decompressor.
+
+   Reducing the resources has potential synchronization issues and so
+   SHOULD NOT be done unless absolutely necessary.  If this is the case
+   then the memory MUST NOT be reclaimed until the remote endpoint has
+   acknowledged the message sent with the advertisement.  If state is to
+   be deleted to accommodate a reduction in SMS then both endpoints MUST
+   delete it according to the state retention priority (see RFC 3320-
+   Section 6.2).  The compressor MUST NOT then use more than the amount
+   of resources most recently advertised.
+
+10.3.  Advertisement of Locally Available State Items
+
+   RFC 3320-Section 3.3.3 defines locally available state items to be
+   the pieces of state that an endpoint has available but that have not
+   been uploaded by the SigComp message.  The examples given are
+   dictionaries and well known pieces of bytecode; and the advertisement
+   mechanism discussed in RFC 3320-Section 9.4.9 provides a way for the
+   endpoint to advertise the pieces of locally available state that it
+   has.
+
+   However, SigComp [1] does not (nor was it ever intended to) fully
+   define the use of locally available state items, in particular, the
+   length of time for which they will be available.  The use of locally
+   available state items is left for definition in other documents.
+   However, this fact, coupled with the fact that SigComp does contain
+   some hooks for uses of locally available state items and the fact
+   that some of the definitions of such uses (in SigComp Extended [2])
+
+
+
+Surtees, et al.             Standards Track                    [Page 17]
+
+RFC 4896         SigComp Corrections and Clarifications        June 2007
+
+
+   are incomplete has caused some confusion.  Therefore, this section
+   clarifies the situation.
+
+   Note that any definitions of uses of locally available state items
+   MUST NOT conflict with any other uses.
+
+10.3.1.  Basic SigComp
+
+   SigComp provides a mechanism for an endpoint to advertise locally
+   available state (RFC 3320-Section 9.4.9).  If the endpoint receiving
+   the advertisement does not 'recognize' it and therefore know the
+   properties of the state e.g., its length and lifetime, the compressor
+   needs to consider very carefully whether or not to access the state;
+   especially if NACK [3] is not available.
+
+   SigComp provides the following hooks for use in conjunction with
+   locally available state items.  Without further definition, locally
+   available state SHOULD NOT be used.
+
+   RFC 3320-Section 6.2 allows for the possibility to map locally
+   available state items to a compartment and states that, if this is
+   done, the state items MUST have state retention priority 65535 in
+   order to not interfere with state created at the request of the
+   remote compressor.  Note that Section 5.3 also recommends that only
+   one such piece of state SHOULD be created per compartment.
+
+   The I-bit in the requested_feedback_location (see RFC 3320-Section
+   9.4.9) allows a compressor to indicate to the remote endpoint that it
+   will not reference any of the previously advertised locally available
+   state.  Depending on the implementation model for state handling at
+   the remote endpoint, this could allow the remote endpoint to reclaim
+   the memory being used by such state items.
+
+10.3.2.  Dictionaries
+
+   The most basic use of the local state advertisement is the
+   advertisement of a dictionary (e.g., the dictionary specified by SIP/
+   SDP Static Dictionary [4]) or a piece of bytecode.  In general, these
+   pieces of state:
+
+   o  are not mapped to compartments
+   o  are local to the endpoint
+   o  are available for at least the duration of the compartment
+   o  do not have any impact on the compartment SMS
+
+   However, for a given piece of state the exact lifetime needs to be
+   defined e.g., in public specifications such as SigComp for SIP [7] or
+
+
+
+
+Surtees, et al.             Standards Track                    [Page 18]
+
+RFC 4896         SigComp Corrections and Clarifications        June 2007
+
+
+   the 3GPP IMS specification [10].  Such a specification should also
+   indicate whether or not advertisement of the state is needed.
+
+10.3.3.  SigComp Extended Mechanisms
+
+   SigComp Extended [2] defines some uses of local state advertisements
+   for which additional clarification is provided here.
+
+   Shared-mode (see RFC 3321-Section 5.2) is well-defined (when combined
+   with the clarification in Section 5.3).  In particular, the states
+   that are created and advertised are mapped into the compartment, have
+   the minimum retention priority and persist only until they are
+   deleted by the creation of new (non-minimum retention priority) state
+   or use of a STATE-FREE instruction.
+
+   The definition of endpoint initiated acknowledgments (RFC 3321-
+   Section 5.1.2) requires clarification in order to ensure that the
+   definition does not preclude advertisements being used to indicate
+   that state will be kept beyond the lifetime of the compartment (as
+   discussed in SigComp for SIP [7]).  Thus the clarification is:
+
+      Where Endpoint A requests state creation at Endpoint B, Endpoint B
+      MAY subsequently advertise the hash of the created state item to
+      Endpoint A.  This conveys to Endpoint A (i) that the state has
+      been successfully created within the compartment; and (ii) that
+      the state will be available for at least the lifetime of the state
+      as defined by the state deletion rules according to age and
+      retention priority of SigComp [1].  If the state is available at
+      Endpoint B after it would be deleted from the compartment
+      according to [1], then the state no longer counts towards the SMS
+      of the compartment.  Since there is no guarantee of such state
+      being available beyond its normally defined lifetime, endpoints
+      SHOULD only attempt to access the state after this time where it
+      is known that NACK [3] is available.
+
+11.  Uncompressed Bytecode
+
+   It is possible to write bytecode that simply instructs the
+   decompressor to output the entire message (effectively sending it
+   uncompressed, but within a SigComp message).  This is particularly
+   useful if the bytecode is well-known (so that decompressors can
+   recognize and output the bytes without running a VM if they wish);
+   therefore, it is documented here.
+
+
+
+
+
+
+
+
+Surtees, et al.             Standards Track                    [Page 19]
+
+RFC 4896         SigComp Corrections and Clarifications        June 2007
+
+
+   The mnemonic code is:
+
+   at (0)
+   :udvm_memory_size         pad (2)
+   :cycles_per_bit           pad (2)
+   :sigcomp_version          pad (2)
+   :partial_state_id_length  pad (2)
+   :state_length             pad (2)
+   :reserved                 pad (2)
+   at (64)
+   :byte_copy_left           pad (2)
+   :byte_copy_right          pad (2)
+   :input_bit_order          pad (2)
+   :stack_location           pad (2)
+
+   ; Simple loop
+   ;       Read a byte
+   ;       Output a byte
+   ; Until there are no more bytes!
+
+   at (128)
+   :start
+   INPUT-BYTES (1, byte_copy_left, end)
+   OUTPUT (byte_copy_left, 1)
+   JUMP (start)
+
+   :end
+   END-MESSAGE (0,0,0,0,0,0,0)
+
+   which translates to give the following SigComp message:
+
+   0xf8, 0x00, 0xa1, 0x1c, 0x01, 0x86, 0x09, 0x22, 0x86, 0x01, 0x16,
+   0xf9, 0x23
+
+12.  RFC 3485 SIP/SDP Static Dictionary
+
+   SIP/SDP Static Dictionary [4] provides a dictionary of strings
+   frequently used in SIP and SDP messages.  The format of the
+   dictionary is the list of strings followed by a table of offset
+   references to the strings so that a compressor can choose to
+   reference the address of the string or the entry in the table.  Both
+   parts of the dictionary are divided into 5 prioritized sections to
+   allow compressors to choose how much of it they use (which is
+   particularly useful in the case where it has to be downloaded).  If
+   only part of the dictionary is used, then the corresponding sections
+   of both parts (strings and offset table) are used.
+
+
+
+
+
+Surtees, et al.             Standards Track                    [Page 20]
+
+RFC 4896         SigComp Corrections and Clarifications        June 2007
+
+
+   However, there are some minor bugs in the dictionary.  In a number of
+   places, the entry in the offset table refers to an address that is
+   not in the corresponding priority section in the list of strings.
+   Consequently, if the bytecode uses the offset table and limits use of
+   the dictionary to priorities less than 4, then care must be taken not
+   to use the following strings in the dictionary:
+
+      'application' at 0x0334 is not at priority 2 (it's priority 4)
+      'sdp' at 0x064b is not at priority 2 (it's priority 4)
+      'send' at 0x089d is not at priority 2 (it's priority 3)
+      'recv' at 0x0553 is not at priority 2 (it's priority 4)
+      'phone' at 0x00f2 is not at priority 3 (it's priority 4)
+
+   This document does not correct the dictionary, as any changes to the
+   dictionary itself would be non-backwards-compatible, and require all
+   implementations to maintain two different copies of the dictionary.
+   Such a cost is far too high for a bug that is trivial to work around
+   and has a negligible effect on compression ratios.  Instead, the flaw
+   is pointed out to allow implementers to avoid any consequent
+   problems.  Specifically, if the bytecode sent to a remote endpoint
+   contains instructions that load only a sub-portion of the SIP/SDP
+   dictionary, then the input stream provided to that bytecode cannot
+   reference any of these five offsets in the offset table, unless the
+   corresponding string portion of the dictionary has also been loaded.
+   For example, if bytecode loads only the first three priorities of the
+   dictionary (both string and offset table), use of the offset for
+   "send" (at 0x089d) would be valid; however, use of the offset for
+   "phone" (at 0x00f2) would not.
+
+13.  Security Considerations
+
+   This document updates SigComp [1], SigComp Extended [2], and the
+   SigComp Static Dictionary [4].  The security considerations for [2]
+   and [4] are the same as for [1]; therefore, this section discusses
+   only how the security considerations for [1] are affected by the
+   updates.
+
+   Several security risks are discussed in [1].  These are discussed
+   briefly here; however, this update does not change the security
+   considerations of SigComp:
+
+      Snooping into state of other users - this is mitigated by using at
+      least 48 bits from the hash.  This update does not reduce the
+      minimum and recommends use of more bits under certain
+      circumstances.
+
+
+
+
+
+
+Surtees, et al.             Standards Track                    [Page 21]
+
+RFC 4896         SigComp Corrections and Clarifications        June 2007
+
+
+      Faking state or making unauthorized changes - this is mitigated by
+      the fact that the application layer has to authorize state
+      manipulation.  This update does not change that mechanism.
+
+      Use of SigComp as a tool in a Denial of Service (DoS) attack -
+      this is mitigated by the fact that SigComp only generates one
+      decompressed message per incoming compressed message.  That is not
+      changed by this update.
+
+      Attacking SigComp as the DoS target by filling with state - this
+      is mitigated by the fact that the application layer has to
+      authorize state manipulation.  This update does not change that
+      mechanism.
+
+      Attacking the UDVM by sending it looping code - this is mitigated
+      by the upper limit of "UDVM cycles", which is unchanged by this
+      update.
+
+14.  IANA Considerations
+
+   This document updates SigComp [1], but does not change the version.
+   Consequently, the IANA considerations are the same as those for [1].
+
+   This document updates SigComp Extended [2], but does not change the
+   version.  Consequently, the IANA considerations are the same as those
+   for [2].
+
+   This document updates Static Dictionary [4], but does not change the
+   version.  Consequently, the IANA considerations are the same as those
+   for [4].
+
+15.  Acknowledgements
+
+   We would like to thank the following people who, largely through
+   being foolish enough to be authors or implementors of SigComp, have
+   provided us their confusion, suggestions, and comments:
+
+      Richard Price
+      Lajos Zaccomer
+      Timo Forsman
+      Tor-Erik Malen
+      Jan Christoffersson
+      Kwang Mien Chan
+      William Kembery
+      Pekka Pessi
+
+
+
+
+
+
+Surtees, et al.             Standards Track                    [Page 22]
+
+RFC 4896         SigComp Corrections and Clarifications        June 2007
+
+
+16.  References
+
+16.1.  Normative References
+
+   [1]   Price, R., Borman, C., Christoffersson, J., Hannu, H., Liu, Z.,
+         and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320,
+         January 2003.
+
+   [2]   Hannu, H., Christoffersson, J., Forsgren, S., Leung, K., Liu,
+         Z., and R. Price, "Signaling Compression (SigComp) - Extended
+         Operations", RFC 3321, January 2003.
+
+   [3]   Roach, A., "A Negative Acknowledgement Mechanism for Signaling
+         Compression)", RFC 4077, October 2004.
+
+   [4]   Garcia-Martin, M., Borman, C., Ott, J., Price, R., and A.
+         Roach, "The Session Initiation Protocol (SIP) and Session
+         Description Protocol (SDP) Static Dictionary for Signaling
+         Compression (SigComp)", RFC 3485, February 2003.
+
+   [5]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", RFC 2119, March 1997.
+
+16.2.  Informative References
+
+   [6]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
+         Specifications (ABNF)", RFC 2234, November 1997.
+
+   [7]   Borman, C., Liu, Z., Price, R., and G. Camarillo, "Applying
+         Signaling Compression (SigComp) to the Session Initiation
+         Protocol (SIP)", Work in Progress, November 2006.
+
+   [8]   Ritter, T., "Estimating Population from Repetitions in
+         Accumulated Random Samples", 1994,
+         <http://www.ciphersbyritter.com/ARTS/BIRTHDAY.HTM>.
+
+   [9]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
+         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
+         Session Initiation Protocol", RFC 3261, June 2002.
+
+   [10]  "IP Multimedia Call Control Protocol based on Session
+         Initiation Protocol (SIP)", October 2006.
+
+
+
+
+
+
+
+
+
+Surtees, et al.             Standards Track                    [Page 23]
+
+RFC 4896         SigComp Corrections and Clarifications        June 2007
+
+
+Appendix A.  Dummy Application Protocol (DAP)
+
+A.1.  Introduction
+
+   This appendix defines a simple dummy application protocol (DAP) that
+   can be used for SigComp interoperability testing.  This is handy for
+   SigComp implementations that are not integrated with a SIP stack.  It
+   also provides some features that facilitate the testing of SigComp
+   internal operations.
+
+   The message format is quite simple.  Each message consists of a
+   8-line message-header, an empty line, and an OPTIONAL message-body.
+   The style resembles that of SIP and HTTP.
+
+   The exact message format is given later in augmented Backus-Naur Form
+   (ABNF) [6].  Here are a few notes:
+
+      Each line of message-header MUST be terminated with CRLF.
+
+      The empty line MUST be present even if the message-body is not.
+
+      Body-length is the length of the message-body, excluding the CRLF
+      that separates the message-body from the message-header.
+
+      All strings in the message-header are case-insensitive.
+
+      For implementation according to this appendix, the DAP-version
+      MUST be set to 1.
+
+A.2.  Processing a DAP Message
+
+   A message with an invalid format will be discarded by a DAP receiver
+
+   For testing purposes, a message with a valid format will be returned
+   to the original sender (IP address, port number) in clear text, i.e.,
+   without compression.  This is the case even if the sender requests
+   this receiver to reject the message.  Note that the entire DAP
+   message (message-header + CRLF + message-body) is returned.  This
+   allows the sender to compare what it sent with what the receiver
+   decompressed.
+
+   Endpoint-ID is the global identifier of the sending endpoint.  It can
+   be used to test the case where multiple SigComp endpoints communicate
+   with the same remote SigComp endpoint.  For simplicity, the IPv4
+   address is used for this purpose.
+
+   Compartment-ID is the identifier of the *compressor* compartment that
+   the *sending* endpoint used to compress this message.  It is assigned
+
+
+
+Surtees, et al.             Standards Track                    [Page 24]
+
+RFC 4896         SigComp Corrections and Clarifications        June 2007
+
+
+   by the sender and therefore only unique per sending endpoint; i.e.,
+   DAP messages sent by different endpoints MAY carry the same
+   compartment-ID.  Therefore, the receiver SHOULD use the (endpoint-ID,
+   compartment-ID) pair carried in a message to determine the
+   decompressor compartment identifier for that message.  The exact
+   local representation of the derived compartment identifier is an
+   implementation choice.
+
+   To test SigComp feedback [1], peer compartments between two endpoints
+   are defined in DAP as those with the same compartment-ID.  For
+   example, (endpoint-A, 1) and (endpoint-B, 1) are peer compartments.
+   That means, SigComp feedback for a DAP message sent from compartment
+   1 of endpoint-A to endpoint-B will be piggybacked on a DAP message
+   sent from compartment 1 of endpoint-B to endpoint-A.
+
+   A DAP receiver will follow the instruction carried in message-header
+   line-5 to either accept or reject a DAP message.  Note: line-6 and
+   line-7 will be ignored if the message is rejected.
+
+   A DAP receiver will follow the instruction in line-6 to create or
+   close the decompressor compartment that is associated with the
+   received DAP message (see above).
+
+   If line-7 of a received DAP message-header carries "TRUE", the
+   receiver will send back a response message to the sender.  This
+   allows the test of SigComp feedback.  As mentioned above, the
+   response message MUST be compressed by, and sent from, the local
+   compressor compartment that is a peer of the remote compressor
+   compartment.  Other than this constraint, the response message is
+   just a regular DAP message that can carry arbitrary message-header
+   and message-body.  For example, the "need-response" field of the
+   response can also be set to TRUE, which will trigger a response to
+   response, and so on.  Note that since each endpoint has control over
+   the "need-response" field of its own messages, this does not lead to
+   a dead loop.  A sensible implementation of a DAP sender SHOULD NOT
+   blindly set this field to TRUE unless a response is desired.  For
+   testing, the message-body of a response MAY contain the message-
+   header of the original message that triggered the response.
+
+   Message-seq can be used by a DAP sender to track each message it
+   sends, e.g., in case of losses.  Message loss can happen either on
+   the path or at the receiving endpoint (i.e., due to decompression
+   failure).  The assignment of message-seq is up to the sender.  For
+   example, it could be either assigned per compartment or per endpoint.
+   This has no impact on the receiving side.
+
+
+
+
+
+
+Surtees, et al.             Standards Track                    [Page 25]
+
+RFC 4896         SigComp Corrections and Clarifications        June 2007
+
+
+A.3.  DAP Message Format in ABNF
+
+   (Note: see (ABNF) [6] for basic rules.)
+
+DAP-message = message-header CRLF [ message-body ]
+
+message-body = *OCTET
+
+message-header = line-1 line-2 line-3 line-4 line-5 line-6 line-7 line-8
+
+line-1 = "DAP-version" ":" 1*DIGIT CRLF
+line-2 = "endpoint-ID" ":" IPv4address CRLF
+line-3 = "compartment-ID" ":" 1*DIGIT CRLF
+line-4 = "message-seq" ":" 1*DIGIT CRLF
+line-5 = "message-auth" ":" ( "ACCEPT" / "REJECT" ) CRLF
+line-6 = "compartment-op" ":" ( "CREATE" / "CLOSE" / "NONE" ) CRLF
+line-7 = "need-response" ":" ( "TRUE" / "FALSE" )
+line-8 = "body-length" ":" 1*DIGIT CRLF
+
+IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
+
+A.4.  An Example of a DAP Message
+
+      DAP-version: 1
+      endpoint-ID: 123.45.67.89
+      compartment-ID: 2
+      message-seq: 0
+      message-auth: ACCEPT
+      compartment-op: CREATE
+      need-response: TRUE
+      body-length: 228
+
+   This is a DAP message sent from SigComp endpoint at IP address
+   123.45.67.89.  This is the first message sent from compartment 2.
+   Please accept the message, create the associated compartment, and
+   send back a response message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Surtees, et al.             Standards Track                    [Page 26]
+
+RFC 4896         SigComp Corrections and Clarifications        June 2007
+
+
+Authors' Addresses
+
+   Abigail Surtees
+   Siemens/Roke Manor Research
+   Roke Manor Research Ltd.
+   Romsey, Hants  SO51 0ZN
+   UK
+
+   Phone: +44 (0)1794 833131
+   EMail: abigail.surtees@roke.co.uk
+   URI:   http://www.roke.co.uk
+
+
+   Mark A. West
+   Siemens/Roke Manor Research
+   Roke Manor Research Ltd.
+   Romsey, Hants  SO51 0ZN
+   UK
+
+   Phone: +44 (0)1794 833311
+   EMail: mark.a.west@roke.co.uk
+   URI:   http://www.roke.co.uk
+
+
+   Adam Roach
+   Estacado Systems
+   17210 Campbell Rd.
+   Suite 250
+   Dallas, TX  75252
+   US
+
+   Phone: sip:adam@estacado.net
+   EMail: adam@estacado.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Surtees, et al.             Standards Track                    [Page 27]
+
+RFC 4896         SigComp Corrections and Clarifications        June 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Surtees, et al.             Standards Track                    [Page 28]
+