Network Working Group H.
Hannu (Editor),Hannu, Ericsson INTERNET-DRAFT J. Christoffersson, Ericsson Expires: JulyAugust 2002 C. Clanton, NokiaS. Forsgren. Ericsson K. Le, Nokia K.Leung, Nokia Z. Liu, Nokia R. Price, Siemens/Roke Manor J. Rosenberg, Dynamicsoft K. Svanbro, Ericsson January 28,February 15, 2002 SigComp - Extended Operations <draft-ietf-rohc-sigcomp-extended-00.txt><draft-ietf-rohc-sigcomp-extended-01.txt> Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is a submission of the IETF ROHC WG. Comments should be directed to its mailing list, email@example.com. Abstract This document defines extended operation mechanisms, explicit acknowledgements and shared compression, for [SIGCOMP]. When these extended SigComp implementations communicatemechanisms are applied an increase of the compression efficiency is expected. 0. Document History - January 28, 2002, version 00 First version. This draft describes the extended operation mechanisms, explicit acknowledgements and shared compression from draft-ietf-rohc-sigcomp-02.txt.Table of contents 1. Introduction..................................................2 2. Terminology...................................................2 3. The Extended SigComp Architecture.............................4Architectural view for feedback...............................4 4. State reference model.........................................5 4.1. Overview of state reference with dynamic compression........65. Extended operation mechanisms.................................7 5.1. Explicit acknowledgement scheme.............................7 5.2. Shared Compression..........................................7mechanisms.................................6 6. Implications on SigComp.......................................8 6.1. Acknowledgement optimization................................9 6.2. Saving state information....................................9SigComp.......................................9 7. Security considerations......................................10considerations......................................14 8. IANA considerations..........................................10considerations..........................................14 9. Acknowledgements.............................................10Acknowledgements.............................................14 10. Authors' addresses...........................................10addresses...........................................14 11. Intellectual Property Right Considerations...................11Considerations...................15 12. References...................................................11References...................................................15 Appendix A. Document history.....................................16 1. Introduction This document defines extended operation mechanisms, explicit acknowledgements and shared compression, for [SIGCOMP]. These mechanisms are expected to improve the compression efficiency between communicating extended SigComp implementations,efficiency, compared to the case when one of the communicating implementations only support the basic SigComp. For better understanding of this draft the reader should consult [SIGCOMP]. 2. 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]. Universal Decompressor Virtual Machine (UDVM) The virtual machine described in [UDVM].[SIGCOMP]. The UDVM is used for decompression of SigComp messages. The UDVM is capable of interoperating with a wide range of compression algorithms. Decompressor The decompressor invokes the UDVM. It is responsible for supplying the UDVM with compressed data and make decompressed data available for the application. Compressor The compressor invokes the encoder, and keeps track of states that can be used for compression. Responsible for supplying UDVM instructions to the peerits remote decompressor in order for compressed data to be decompressed. Explicit acknowledgements Is defined as the case where an acknowledgement for a state is explicitly sent from a decompressor to a compressor. The acknowledgment can either be sent standalone or piggybacked with a SigComp message. Shared compression Is defined as the case when a compressor uses data that has been received by the associated decompressor. Dynamic compression Is defined as the case when a compressor uses data, which are related to previous SigComp messages. Encoder Encodes data according to a (compression) algorithm into UDVM readable code. The encoded data can be decoded by a UDVM provided with the needed instructions. Application Invokes the SigComp compressor and decompressor. State Data saved either by a compressor or a decompressor. The data reflects the contents of a UDVM memory. State indexidentifier Reference to a state saved either by a compressor or a decompressor. - state_indexstate_identifier This is a reference to a state, which a compressor uses for compression. - shared_indexshared_identifier This is a reference to a state, which consist only of an uncompressed message. This kind of state is necessary for efficient utilization of shared compression, as peerremote compressors might use different compression algorithms. - acked_indexacked_identifier This is a reference to a state, which is acknowledged and saved by a decompressor. SigComp message May contain a compressed application message in the form of UDVM bytecode. In case of a message oriented transport mechanism,message- based transport, such as UDP, a SigComp message corresponds to exactly one (UDP) packet.datagram. For a stream orientedstream-based transport, such as TCP, each SigComp message is separated by a 0xFFFF delimiter, see [UDVM].delimiter. Application data (message) Data, also referred to asmessage An uncompressed message, as provided from or to the application, which is to be compressed by the compressor. When delivered from the decompressor the data has passed through the decompression process and is referred to as decompressed data or a decompressed message. 3. The ExtendedArchitectural view for feedback A SigComp Architecture Compression and decompression is performed at two communicating end- points,endpoint may provide feedback to its remote SigComp endpoint, see Figure 1. +--------------------+ +--------------------+ | Compressor 1 | | DecompressorEndpoint 1 | | +---------+ | | +---------+ | | | Encoder | | | | UDVM | | | +---------+ | | +---------+ | +--------------------+ +--------------------+ ^ ^ App. ^ | ^ | App. ^ | | | data | | | v data | v +-|--|-------------|-+ +-|-------------|--|-+ | | | | | SigComp | | | | | |[E] | Application v | message | | Application | | | | | v +---------->----------+ vEndpoint 2 | | +--------------+ | | +-------++--------------+ | | +-------+| Compressor | | | | StateDecompressor | | Data transport| | State[------------+--+--------------+--+--] * | | | +-|-------^----+ | | +-------++--|---|-------+ | | +-------+| | | | ^ +----------<----------+ ^| | | | | | | SigComp| ^| [E]|| | | | | message| | | | | +-|--|-------------|-+ +-|-------------|--|-+ ^| App. ^+-|-------|----+ | | +--v---|-------+ | App.| | * [----+--+--------------+--+------] | v data| v| v data v v +--------------------+ +--------------------+| Decompressor 2 | | Compressor 2 | | +---------+ | | +---------+ | | | UDVM| | | | EncoderCompressor | | | +---------++--------------+ | | +---------++--------------+ | +--------------------+ +--------------------+ Figure 1. Extended SigComp High-level view. The difference between SigComp and extended SigComp is the availability of "interface" E (symbol [E]).Architectural view With the extended operation, explicit acknowledgements (symbol [E]),feedback format specified in Section 6, it is possible for e.g. decompressor 1a SigComp endpoint to inform compressor 1 aboutconfirm which states that have been established at decompressor 1. Compressor 1 can then use these states in the compression process.to its remote SigComp endpoint. The established state confirmations are referred to as acknowledgments. Depending on the established states,states this is expectedparticular type of feedback may be used to increase the compression efficiency. See Section 6 for the extended SigComp message format.4. State reference model A UDVM [UDVM]may want to save the status of its memory. Thismemory and this status is referred to as a state. The decompressor may allow theAs explained in [SIGCOMP] a save state torequest may or may not be saved.granted. For later reference to thisa saved state, e.g. if the UDVM is to be loaded with this state, a reference is needed to locate the specific state. This reference is called state index.identifier. 4.1. Overview of state reference with dynamic compression When compressor 1 (comp_1) compresses a message M it uses the information corresponding to a UDVM state that the peerits remote decompressor (decomp_1)(decomp_2) has established and acknowledged. If comp_1 decides that it for compression of later messages would like to be able to use the new state, which is the former state with the addition of information from M, it must save the new state. If an acknowledgement is received for this new state, comp_1 can utilize the new state in the compression process. Below is an overview of the model. Available state(s) Compressor: The state is anticipated for compression of later messages, and is therefore saved. Decompressor: The decompressor saves the state if it will acknowledge it. An acknowledged state may be used for compression. Acked state(s) The compressor can only use a state(s) that the peerremote decompressor has saved and acknowledged. Compressor 1 Decompressor 12 +---+ +---+ | C | | D | +---+ +---+ Available Acked | | Available State(s) State(s) | | State(s) -----------------------+------------+------------------ s0 s0 | | s0 s1=s0+m1 | --m1(s0)-->| | <--ack(s1) | s0,s1 s0,s1 s0,s1 | | | | s0,s1 s0,s1 | --m2(s1)-->| (m2 Lost) s2=s1+m1 | | | | s0-s2 s0,s1 | | s3=s1+m3 | --m3(s1)-->| s0,s1 | | | | | <--ack(s3) | s0,s1,s3=s1+m3 s0-s3 s0,s1,s3 | | Figure 2. Example of message flow. 5. Extended operation mechanisms For a compressor to be able to utilize a certain state it must know that the peerremote decompressor has access to this state. In case where compressed messages can be lost or misordered on the path between compressor and decompressor, some sort of acknowledgement must be used by a decompressor to notify the peerremote compressor that a certain state has been established. Over reliable and ordered transport the most recent state can alwaysmay be used, if the compressor has downloaded such a UDVM instruction code to the peerits remote decompressor. The following subsections describe how an explicit acknowledgement scheme and shared compression can be usedapplied in SigComp. 5.1. Explicit acknowledgement scheme As described above, aA SigComp message will along with the compressed message carry a reference to which state that was used for compression of the message. This reference is the state_index,state_identifier, as described in Section 2. Together with state_indexstate_identifier the SigComp message may also carry an acknowledgement, which would be the acked_index,acked_identifier, see Section 2. The acknowledgement can be either standalone or piggybacked. For security reasons as explained in SigComp it is RECOMMENDED that this particular feedback is piggybacked and not sent standalone. 5.2. Shared Compression To allow for shared compression a compressor mustcompressing endpoint MUST save a state, which is the uncompressed version of the compressed message. The reference to this uncompressed version is the shared_index,shared_identifier, as described in Section 2. It must also indicate to the peerits remote decompressor that this compressed message's uncompressed version was saved as a state at the compressor. WhenIf a decompressor receivescompressing endpoint indicates that a compressed message utilizingshared compression, the state indicated by state_index in the SigComp message is loaded to the UDVM. Thereafter thecompression state indicated by shared_state is loadedwas saved, its local decompressor MUST be able to the UDVM.retrieve that particular state. The sharedretrieval of this particular state is loaded to the UDVM by setting the first_token to the shared_pointer (a pointer at a defined position), which pointsdone according to the code that will insert the sharedstate into the "live dictionary"retrieval instructions of the UDVM. The shared5.3. Maintaining state data is copied into compressed_start and compressed_end is updated, andacross session Usually, signaling protocols (e.g. SIP) have the UDVM is invoked. Then first_tokenconcept of sessions. However, from the compression point of view, the messages sent by the same source contain redundancies beyond session boundary. Consequently, it is setnatural to its previous value, andmaintain the messagestate data from the same source across sessions so that high performance can be compressed by invoking the UDVM. 6. Implications on SigComp Forachieved and maintained with the supportoverhead amortized over a much longer period of time than a session. 5.4. Use of user-specific dictionary The concept of user-specific dictionary is based on the extended operation mechanisms, SigCompfollowing observation that for protocols such as SIP, a given user/device combination will produce some messages must be able to carrycontaining fields that are always populated with the indicationssame data. Take SIP as an example, capabilities of the SIP endpoints are communicated during session initiation, and information addressed in Section 5. A decompressor that doesdo not support the extended operations, must be abletend to derive the length ofchange unless the device's capabilities change. Similarly, user-specific information such as a user's URL, a user's name, and a user's e-mail address likely won't change on frequent basis, and will appear regularly in SIP signaling exchanges involving a specific user. Therefore, a SigComp message, which the peercompressor might have added forcould start uploading the extended operationuser- specific dictionary, as part of the initial state, to the decompressor even before any signaling messages are generated from a particular application . This enables the immediate compression/decompression once the messages start to flow. 5.5. Checkpoint state and rollback mechanism The following mechanisms can be used to recover from decompression failure due to a reference to a non-exist state (i.e. not established at all or has been deleted by the decompressor) or a corrupted state: 1) When a compressor sends a compressed message that will create new decompression state on the decompressor side, it can set a CHK_PT bit in the message to indicate that the newly created state will be a checkpoint state. A checkpoint state means that the decompressor SHOULD NOT delete it until it is explicitly instructed -- by the compressor -- to do so. In addition, the checkpoint state MUST be explicitly acknowledged by the receiving decompressor to the sending compressor. 2) When a decompressor encounters a decompression failure as described above, it can send a rollback message to its remote compressor indicating such a failure. In addition, the rollback message may carry a list of state IDs of those checkpoint states that are currently maintained by the decompressor. This is useful in the case when the decompressor has to delete even checkpoint states due to limited memory. When receiving such a rollback message, the compressor MUST NOT use any state to compress subsequent messages other than those explicitly listed in the rollback message or if the list is empty, than those checkpoint states it stores locally and have been acknowledged. 5.6. Implicit deletion when creating a new state To achieve the maximum compression efficiency, a compressor may want to delete part (e.g. dictionary part) of byte buffer to make room for the new content. This is especially important when implementing SigComp with limited memory (as in the case of a mobile terminal). With the implicit deletion, some part(s) of the byte buffer are chosen to be deleted according to a well defined algorithm that is known and applied in the same way at both compressor and decompressor. As input into the algorithm, one provides the total size to be deleted (e.g. number of bytes), and the algorithm specifies which part(s) are to be deleted. The freed room can then allow new content to be added to the byte buffer. Since the same algorithm is applied at both SigComp entities, there is no need to explicitly signal which part(s) have been deleted. In particular, when the allocated memory has been filled up, each SigComp entity, when it wants to add items of combined size S, will implicitly delete part(s) of combined size S. Since there is no need for signaling, the scheme is more efficient (lower signaling overhead) and more robust (less prone to errors or losses affecting the signaling information). For example, the implicit deletion may be applied to the entire writable UDVM memory defined by working_memory_start and working_memory_end or only some parts of the writable UDVM memory. In the latter case, it is assumed that the peer SigComp entities agree on which parts the operation is applied to and the total size of those parts. 6. Implications on SigComp The extended operations will have implication on the SigComp messages sent between the compressor and the remote decompressor. It will also have implications on the interface between the UDVM and its local decompressor functionalities. 6.1. Implications on SigComp messages For the support of the extended operation mechanisms, SigComp messages must be able to carry the indications and information addressed in Section 5. The basic SigComp message has the following format: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | | : state_identifier (n-bytes) : | | +---+---+---+---+---+---+---+---+ | | : Remaining UDVM bytecode : | | +---+---+---+---+---+---+---+---+ Figure 3. Format of basic SigComp message. The content of the UDVM byte code is an implementation decision. However, in the case of extended operations it should convey the following information: - The shared_identifier as described in Section 2, and Section 5.2, MUST be conveyed when shared compression is applied. - State identifiers of states that are acknowledged as successfully saved by the decompressor, i.e. acked_identifiers. Figure 4, depicts an example of what an extended basic SigComp message, with the support of all extended operation mechanisms, could look like. Note that this is only an example, the format is an implementation decision. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | | : state_identifier (n-bytes) : | | +---+---+---+---+---+---+---+---+ | s | a | r | b | Reserved | +---+---+---+---+---+---+---+---+ | | : shared_identifier (n-bytes) : Present if 's' is set | | +---+---+---+---+---+---+---+---+ | | : acked_identifier (n-bytes) : Present if 'a' is set | | +---+---+---+---+---+---+---+---+ | Possible | : Compressed data : | | +---+---+---+---+---+---+---+---+ Figure 4. Example of SigComp message for extended operations. 'r' : If set, then a state corresponding to the decompressed version of this compressed message was saved at the compressor. 'b' : Explained in Section 6.2.3. For the explanation of (n-bytes) see [SIGCOMP]. 6.2. Implications on the UDVM-decompressor interface This interface is used to pass feedback information from the UDVM to its local decompressor. The decompressor then forwards this information on to the local compressor. 6.2.1. General SigComp feedback format The general SigComp feedback information has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDVM_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | overall_memory_size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cycles_per_bit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cycles_per_message | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requested feedback length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Requested feedback : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Returned feedback length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Returned feedback : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5. High-level view of general SigComp feedback information. For description of the items see [SIGCOMP]. In case that shared compression and/or explicit acknowledgements are not supported[SigComp]. The following Section describes how the informationgeneral feedback format is discarded before theused to provided extended operation mechanisms to basic sigComp. 6.2.2. Extended SigComp messagerequested feedback format The requested feedback is processed any further. Figure 1, depicts a complete SigComp message,feedback from the UDVM to its remote compressor. To make the extended acknowledgement scheme work, the Requested feedback is filled with information on states that UDVM requests the supportstate handler to save. In case the state handler refuses to save one or more of all extended operation mechanisms. An Optimizationthe indicated states, the feedback sent from the compressor will be updated accordingly. The format of this messagethe Requested feedback is also shown and explainedof the following form: The variable n specifies the number of state identifiers included in Section 6.1. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | i | cthe extended operations feedback format. id_length (x) and id_values (x) corresponds to the same state. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sn | a+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | rid_length 1 | b |Reserv.| +---+---+---+---+---+---+---+---++-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : state_index (n-bytes)id_value_1 : Present if 'i' is set | | +---+---+---+---+---+---+---+---+| | : CRC : Present if 'c' is set+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | id_length 2 | +---+---+---+---+---+---+---+---++-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : shared_index (n-bytes)id_value_2 : Present if 's' is set | | +---+---+---+---+---+---+---+---+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : acked_index (n-bytes): Present if 'a' is set: : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | id_length n | +---+---+---+---+---+---+---+---++-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Possible| : Compressed data that shouldid_value_n : | be given as input to the UDVM| +---+---+---+---+---+---+---+---++-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1.6. Format of the Requested feedback. 6.2.2. Extended SigComp message. 'r' : If set, then a state correspondingreturned feedback format The returned feedback is feedback from the remote endpoint to the decompressedlocal compressor. The 'r' bit indicates that an uncompressed version of thisthe compressed message wassent in this message has been saved at the compressor.remote endpoint, with the demands of Section 5.2. The 'b' bit is explained in Section 6.2.3. The format of the returned feedback is of the following form: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |r|b| n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | id_length 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : id_value_1 : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | id_length 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : id_value_2 : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | id_length n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Explained in Section 6.1. The CRC is calculated over the uncompressed message and can e.g. be used for verificationid_value_n : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7. Format of successful decompression. Forthe explanation of (n-bytes) see [SIGCOMP]. 6.1.Returned feedback. 6.2.3. Acknowledgement optimization This section describes an optimization for the case when shared compression is used and an acknowledgement is piggybacked. Consider the following.following scenario. Comp_1 sends a message M compressed, with state(s0) to decomp_1. As comp_1 supports shared compression it saves state(M), and sets bit 'r', to signal that state(M) can be used by comp_2 in the compression process. If decomp_1 saves state(s0+M) = state(s1), which is the new state of the UDVM after decompression of M, then state(s1) can be implicitly acknowledged, if comp_2 uses M for further compression. Comp_2 sets the 'b' bit, which indicates that state(s0+M) is saved, which can be found from state(M), which is referenced by shared_index.shared_identifier. This avoids acked_indexacked_identifier to be present in the SigComp message for state(s0+M). Thus, a compressor that sets the 'r' bit should also hold a mapping between state(M) and state(s0+M). Note: The only state that this feature acknowledges, is the state that was created by combining the state used for compression of the shared message and the shared message itself. For any other case the acked_indexacked_identifier has to be used. 6.2. Saving state information There are some simple rules, which must be followed, when a state is to be saved. Decompressor If there already exists a state for a state index, it must not be replaced with the requested state to be saved. This is to avoid that a compressed message cannot be decompressed because its state has been replace with another one. Compressor If there already exists a state for a state index, generated by the compressor, the compressor must not use that state for compression of any later messages even if an acknowledgement for this state is received. These states (state indexes) should be kept for a reasonable amount of time to avoid that a state used by the compressor is not actually the same as the one stored at the peer decompressor, even though the state index is the same.7. Security considerations The features in this document are believed not to add any additional security risks to the ones in [SIGCOMP] and [UDVM].[SIGCOMP]. 8. IANA considerations [Editors note: This section is TBW] 9. Acknowledgements [Editors note: This section is TBW]TBW. Some names have been moved here from the list of authors] Thanks to Carsten Bormann (firstname.lastname@example.org) Christopher Clanton (email@example.com) Miguel Garcia (Miguel.A.Garcia@ericsson.com) Lars-Erik Jonsson (firstname.lastname@example.org) Khiem Le (email@example.com) Mats Nordberg (firstname.lastname@example.org) Jonathan Rosenberg (email@example.com) Krister Svanbro (firstname.lastname@example.org) for valuable input and review. 10. Authors' addresses Hans Hannu, EditorHannu Phone: +46 920 20 21 84 Fax: +46 920 20 20 99 E-Mail: email@example.com Jan Christoffersson Phone: +46 920 20 28 40 Fax: +46 920 20 20 99 E-Mail: firstname.lastname@example.org Stefan Forsgren Phone: +46 920 20 23 39 Fax: +46 920 20 20 99 E-Mail: email@example.com Krister Svanbro Phone: +46 920 20 20 77 Fax: +46 920 20 20 99 E-Mail: firstname.lastname@example.orgBox 920 Ericsson Erisoft AB SE-971 28 Lulea, Sweden Christopher Clanton Phone: +1 972 894-4886 Fax: +1 972 894-4589 E-mail: email@example.com Khiem Le Phone: +1 972 894-4882 Fax: +1 972 894-4589 E-mail: firstname.lastname@example.orgKa Cheong Leung Phone: +1 972 374-0630 Fax: +1 972 894-4589 E-mail: email@example.com Zhigang Liu Phone: +1 972 894-5935 Fax: +1 972 894-4589 E-Mail: firstname.lastname@example.org Nokia Research Center 6000 Connection Drive Irving, TX 75039, USA Richard Price Phone: +44 1794 833681 E-mail: email@example.com Roke Manor Research Ltd Romsey, Hants, SO51 0ZN United Kingdom Jonathan Rosenberg E-mail: firstname.lastname@example.org dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 0793611. Intellectual Property Right Considerations The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 12. References [SIP] Handley et. al., SIP: Session Initiation Protocol, RFC 2543, Internet Engineering Task Force, March 1999 [SIGCOMP] H. Hannu et. al., Signaling Compression (SigComp), Internet Draft (work in progress), JanuaryFebruary 2002. <draft-ietf-rohc-sigcomp-03.txt> [UDVM] R. Price et. al., Universal Decompressor Virtual Machine (UDVM), Internet Draft (work in progress),<draft-ietf-rohc-sigcomp-04.txt> Appendix A. Document history - January 2002. <draft-ietf-rohc-sigcomp-udvm-00.txt>28, 2002, version 00 First version. This draft describes the extended operation mechanisms, explicit acknowledgements and shared compression from draft-ietf-rohc-sigcomp-02.txt. - February 15, 2002, version 01 Second version. Updated to reflect the changes made in [SIGCOMP]. This Internet-Draft expires in JulyAugust 2002.