Robust Header Compression A. Surtees Internet-Draft M. West Expires: August 19, 2005 Siemens/Roke Manor A. Roach Estacado Systems February 18, 2005 Implementer's Guide for SigComp draft-ietf-rohc-sigcomp-impl-guide-04.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 19, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes common misinterpretations and some ambiguities in the Signalling Compression Protocol (SigComp), and offers guidance to developers to clarify any resultant problems. SigComp defines a scheme for compressing messages generated by application protocols such as the Session Initiation Protocol (SIP). Surtees, et al. Expires August 19, 2005 [Page 1] Internet-Draft Implementer's Guide for SigComp February 2005 This document does not address compression specific issues such as different compressor types and bytecode. This information can be found in a separate document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Decompression Memory Size . . . . . . . . . . . . . . . . . . 3 2.1 Bytecode within Decompression Memory Size . . . . . . . . 3 2.2 Default Decompression Memory Size . . . . . . . . . . . . 3 3. UDVM Instructions . . . . . . . . . . . . . . . . . . . . . . 4 3.1 Data Input Instructions . . . . . . . . . . . . . . . . . 4 3.2 STATE-FREE . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Byte Copying Rules . . . . . . . . . . . . . . . . . . . . . . 5 4.1 Instructions That Use Byte Copying Rules . . . . . . . . . 5 5. State Retention Priority . . . . . . . . . . . . . . . . . . . 6 5.1 Priority Values . . . . . . . . . . . . . . . . . . . . . 6 5.2 Multiple State Retention Priorities . . . . . . . . . . . 6 5.3 Retention Priority 65535 (or -1) . . . . . . . . . . . . . 7 6. Duplicate State . . . . . . . . . . . . . . . . . . . . . . . 9 7. State Identifier Clashes . . . . . . . . . . . . . . . . . . . 9 8. The I-bit in Requested Feedback . . . . . . . . . . . . . . . 10 9. Feedback when SMS is zero . . . . . . . . . . . . . . . . . . 11 10. Dynamic Update of Resources . . . . . . . . . . . . . . . . 11 11. Uncompressed bytecode . . . . . . . . . . . . . . . . . . . 12 12. RFC 3485 SIP/SDP Static Dictionary . . . . . . . . . . . . . 12 13. Security Considerations . . . . . . . . . . . . . . . . . . 13 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 A. Dummy Application Protocol (DAP) . . . . . . . . . . . . . . . 15 A.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 15 A.2 Processing a DAP message . . . . . . . . . . . . . . . . . 15 A.3 DAP message format in ABNF . . . . . . . . . . . . . . . . 17 A.4 An example of a DAP message . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 18 Surtees, et al. Expires August 19, 2005 [Page 2] Internet-Draft Implementer's Guide for SigComp February 2005 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 require clarification have been identified. The sections that follow enumerate the problem areas identified in the specification, and attempt to provide clarification. 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 section 7 to be (DMS - sizeof (sigcomp_msg)) 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). It is correct that there are two copies of the bytecode within the decompressor memory, in this case. |<----------------------------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 Surtees, et al. Expires August 19, 2005 [Page 3] Internet-Draft Implementer's Guide for SigComp February 2005 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 should also provide further specification for their application that mandates the use of an appropriately sized DMS. 3. UDVM Instructions 3.1 Data Input Instructions When inputting data from the compressed message, the INPUT-BYTES (section 9.4.2) and INPUT-BITS (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 no bytes/bits should be returned to the UDVM and the m bytes/bits that are there should remain in the message unchanged. For example, the remaining bytes of message are: 0x01 0x02 0x03 and the UDVM encounters an INPUT-BYTES (6, a, b) instruction. 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 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 Surtees, et al. Expires August 19, 2005 [Page 4] Internet-Draft Implementer's Guide for SigComp February 2005 that corresponds to the message being decompressed. Attempting to free state either from another compartment or that is not associated with a compartment has no effect. 4. Byte Copying Rules Section 8.4 of SigComp [1] 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 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 may begin to the left of byte_copy_left and continue across it (and jump back to it according to the given algorithm if necessary) and may 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). 4.1 Instructions That Use Byte Copying Rules 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. Surtees, et al. Expires August 19, 2005 [Page 5] Internet-Draft Implementer's Guide for SigComp February 2005 When state is created by the state-handler (whether the instruction was from END-MESSAGE or STATE-CREATE), the byte copying rules of 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 the list of instructions in Section 8.4 that obey byte copying rules but its description in Section 9.3.5 states that these rules should be obeyed. When reading data over which to perform the crc check byte copying rules apply as specified in Section 8.4. When the partial identifier is read for a STATE-FREE instruction (during the execution of END-MESSAGE) byte copying rules as per 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. 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 should 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 may 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.) Surtees, et al. Expires August 19, 2005 [Page 6] Internet-Draft Implementer's Guide for SigComp February 2005 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 should 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, which are of shared mode SigComp Extended [2] . Example 1: 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 Example 2: Endpoint A Endpoint B [decomp cpt] [comp cpt] [SM1] -------------------------------> [SM1] [SM1, BC, BF1] (message lost)X------ref SM1----- Surtees, et al. Expires August 19, 2005 [Page 7] Internet-Draft Implementer's Guide for SigComp February 2005 [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 Once there is more than one piece of state 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 may 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 loss of synchronisation 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 it may be reasonable to assume that the likelihood of loss of synchronisation is very small and rely on the Surtees, et al. Expires August 19, 2005 [Page 8] Internet-Draft Implementer's Guide for SigComp February 2005 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 behaviour 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 should think carefully about the consequences of creating multiple pieces of minimum priority state. In either case, if the behaviour 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 SIGCOMP-FREE instruction to remove the existing piece of state. 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 the new state retention priority. 7. State Identifier Clashes Section 6.2 of [1] 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 may 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]). Surtees, et al. Expires August 19, 2005 [Page 9] Internet-Draft Implementer's Guide for SigComp February 2005 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 required: 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: 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 should be used to access state at the server. 8. The I-bit in Requested Feedback The I-bit in requested feedback is a mechanism by which a compressor may 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 Surtees, et al. Expires August 19, 2005 [Page 10] Internet-Draft Implementer's Guide for SigComp February 2005 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 on any state that has been created by the sender using END-MESSAGE or STATE-CREATE instructions. 9. 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. 10. 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 (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 synchronisation problem. The compressor must not use more than the most recently advertised resources. Note that the compressor SMS is unofficial (enables compressor to monitor decompressor state) and is separate from the SMS advertised by the decompressor. Reducing the resources has potential synchronisation issues and so should not be done unless absolutely necessary. If this is the case then the memory should not be reclaimed until the remote endpoint has acknowledged the message sent with the advertisement. If state must be deleted to accommodate a reduction in SMS then both endpoints should delete it according to the state retention priority (section 6.2). The compressor should use up to the amount of resources most recently advertised. Surtees, et al. Expires August 19, 2005 [Page 11] Internet-Draft Implementer's Guide for SigComp February 2005 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 messsage). This is particularly useful if the bytecode is well known (so that decompressors can recognise and output the bytes without running a VM if they wish), it is documented here. 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 Surtees, et al. Expires August 19, 2005 [Page 12] Internet-Draft Implementer's Guide for SigComp February 2005 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 prioritised 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. 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) These are seen to be relatively low cost bugs as only these 5 strings are affected and they are only affected under certain conditions. 13. Security Considerations This document provides clarifications to SigComp [1] but does not change it. Consequently the security considerations are the same as those for SigComp [1]. 14. Acknowledgements Largely through being foolish enough to be authors of, or to have implemented, SigComp we would like to thank the following: Richard Price (richard.price@roke.co.uk) Lajos Zaccomer (lajos.zaccomer@ericsson.se) Timo Forsman (timo.forsman@ericsson.se) Tor-Erik Malen (tor-erik.malen@ericsson.se) Jan Christoffersson (jan.christoffersson@ericsson.se) Kwang Mien Chan (chankm@icr.a-star.edu.sg) William Kembery (wkember@lts.ncsc.mil) Pekka Pessi (pekka.pessi@nokia.com) for their confusion, suggestions and comments. 15 References [1] Price, R., Borman, C., Christoffersson, J., Hannu, H., Liu, Z. and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, Surtees, et al. Expires August 19, 2005 [Page 13] Internet-Draft Implementer's Guide for SigComp February 2005 January 2003. [2] Hannu, H., Christoffersson, J., Forsgren, S., Leung, K., Liu, Z. and R. Price, "Signaling Compression (SigComp)", RFC 3321, January 2003. [3] Roach, A., "A Negative Acknowledgement Mechanism for Signaling Compression)", RFC XXXX, 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) Statc Dictionary for Signaling Compression (SigComp)", RFC 3485, February 2003. [5] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 3667, February 2004. [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [7] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications (ABNF)", RFC 2234, November 1997. [8] Ritter, T., "Estimating Population from Repetitions in Accumulated Random Samples", 1994, . Authors' Addresses Abigail Surtees Siemens/Roke Manor 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 Surtees, et al. Expires August 19, 2005 [Page 14] Internet-Draft Implementer's Guide for SigComp February 2005 Mark A. West Siemens/Roke Manor 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 US EMail: adam@estacado.net 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 SIP stack. It also provides some features that facilitate the tests 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. You can see the style resembles that of SIP and HTTP. The exact message format is given later in augmented Backus-Naur Form (ABNF) [7]. Here are a few notes: Each line of message-header must be terminated with CR LF. 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 which separates the message-body from the message-header. All strings in 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 invalid format will be discarded by a DAP receiver Surtees, et al. Expires August 19, 2005 [Page 15] Internet-Draft Implementer's Guide for SigComp February 2005 For testing purpose, a message with 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, 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 by the sender and therefore only unique per sending endpoint. I.e., DAP messages sent by different endpoints may carry 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 must 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 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 the header line-7 of a received DAP message 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 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 either endpoint has control Surtees, et al. Expires August 19, 2005 [Page 16] Internet-Draft Implementer's Guide for SigComp February 2005 over the "need-response" field of its own messages, this does not lead to a dead loop. A sensible implementation of a DAP sender must 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. A.3 DAP message format in ABNF (Note: see (ABNF) [7] 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. Expires August 19, 2005 [Page 17] Internet-Draft Implementer's Guide for SigComp February 2005 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. This Internet-Draft will expire on August 19, 2005. Surtees, et al. Expires August 19, 2005 [Page 18]