< draft-ietf-rohc-sigcomp-user-guide-03.txt		draft-ietf-rohc-sigcomp-user-guide-04.txt >
	Robust Header Compression A. Surtees		Robust Header Compression A. Surtees
	Internet-Draft M. West		Internet-Draft M. West
	Expires: April 1, 2006 Siemens/Roke Manor Research		Expires: April 27, 2006 Siemens/Roke Manor Research
	September 28, 2005		October 24, 2005
	SigComp Users' Guide		SigComp Users' Guide
	draft-ietf-rohc-sigcomp-user-guide-03.txt		draft-ietf-rohc-sigcomp-user-guide-04.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		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 becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on April 1, 2006.		This Internet-Draft will expire on April 27, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	This document provides an informational guide for users of the		This document provides an informational guide for users of the
	SigComp protocol. The aim of the document is to assist users when		SigComp protocol. The aim of the document is to assist users when
	making SigComp implementation decisions; for example the choice of		making SigComp implementation decisions; for example the choice of
	skipping to change at page 2, line 30 ¶		skipping to change at page 2, line 30 ¶
	4.1.2 LZSS . . . . . . . . . . . . . . . . . . . . . . . . . 16		4.1.2 LZSS . . . . . . . . . . . . . . . . . . . . . . . . . 16
	4.1.3 LZW . . . . . . . . . . . . . . . . . . . . . . . . . 18		4.1.3 LZW . . . . . . . . . . . . . . . . . . . . . . . . . 18
	4.1.4 DEFLATE . . . . . . . . . . . . . . . . . . . . . . . 21		4.1.4 DEFLATE . . . . . . . . . . . . . . . . . . . . . . . 21
	4.1.5 LZJH . . . . . . . . . . . . . . . . . . . . . . . . . 24		4.1.5 LZJH . . . . . . . . . . . . . . . . . . . . . . . . . 24
	4.2 Adapted Algorithms . . . . . . . . . . . . . . . . . . . . 28		4.2 Adapted Algorithms . . . . . . . . . . . . . . . . . . . . 28
	4.2.1 Modified DEFLATE . . . . . . . . . . . . . . . . . . . 28		4.2.1 Modified DEFLATE . . . . . . . . . . . . . . . . . . . 28
	5. Additional SigComp mechanisms . . . . . . . . . . . . . . . . 31		5. Additional SigComp mechanisms . . . . . . . . . . . . . . . . 31
	5.1 Acknowledging a state item . . . . . . . . . . . . . . . . 32		5.1 Acknowledging a state item . . . . . . . . . . . . . . . . 32
	5.2 Static dictionary . . . . . . . . . . . . . . . . . . . . 33		5.2 Static dictionary . . . . . . . . . . . . . . . . . . . . 33
	5.3 CRC checksum . . . . . . . . . . . . . . . . . . . . . . . 34		5.3 CRC checksum . . . . . . . . . . . . . . . . . . . . . . . 34
	5.4 Announcing additional resources . . . . . . . . . . . . . 34		5.4 Announcing additional resources . . . . . . . . . . . . . 35
	5.5 Shared compression . . . . . . . . . . . . . . . . . . . . 36		5.5 Shared compression . . . . . . . . . . . . . . . . . . . . 37
	6. Security considerations . . . . . . . . . . . . . . . . . . . 37		6. Security considerations . . . . . . . . . . . . . . . . . . . 38
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38
	8. Intellectual Property Right Considerations . . . . . . . . . . 37		8. Intellectual Property Right Considerations . . . . . . . . . . 38
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39
	A. UDVM bytecode for the compression algorithms . . . . . . . . . 39		A. UDVM bytecode for the compression algorithms . . . . . . . . . 39
	A.1 Well-known Algorithms . . . . . . . . . . . . . . . . . . 39		A.1 Well-known Algorithms . . . . . . . . . . . . . . . . . . 40
	A.1.1 Simplified LZ77 . . . . . . . . . . . . . . . . . . . 39		A.1.1 Simplified LZ77 . . . . . . . . . . . . . . . . . . . 40
	A.1.2 LZSS . . . . . . . . . . . . . . . . . . . . . . . . . 39		A.1.2 LZSS . . . . . . . . . . . . . . . . . . . . . . . . . 40
	A.1.3 LZW . . . . . . . . . . . . . . . . . . . . . . . . . 40		A.1.3 LZW . . . . . . . . . . . . . . . . . . . . . . . . . 40
	A.1.4 DEFLATE . . . . . . . . . . . . . . . . . . . . . . . 40		A.1.4 DEFLATE . . . . . . . . . . . . . . . . . . . . . . . 40
	A.1.5 LZJH . . . . . . . . . . . . . . . . . . . . . . . . . 40		A.1.5 LZJH . . . . . . . . . . . . . . . . . . . . . . . . . 40
	A.2 Adapted Algorithms . . . . . . . . . . . . . . . . . . . . 40		A.2 Adapted Algorithms . . . . . . . . . . . . . . . . . . . . 41
	A.2.1 Modified DEFLATE . . . . . . . . . . . . . . . . . . . 40		A.2.1 Modified DEFLATE . . . . . . . . . . . . . . . . . . . 41
	Intellectual Property and Copyright Statements . . . . . . . . 42		Intellectual Property and Copyright Statements . . . . . . . . 42
	1. Introduction		1. Introduction
	This document provides an informational guide for users of the		This document provides an informational guide for users of the
	SigComp protocol RFC-3320 [4]. The idea behind SigComp is to		SigComp protocol RFC-3320 [4]. The idea behind SigComp is to
	standardize a Universal Decompressor Virtual Machine (UDVM) that can		standardize a Universal Decompressor Virtual Machine (UDVM) that can
	be programmed to understand the output of many well-known compressors		be programmed to understand the output of many well-known compressors
	including DEFLATE [10] and LZW [9]. The bytecode for the choice of		including DEFLATE [10] and LZW [9]. The bytecode for the choice of
	compression algorithm is uploaded to the UDVM as part of the		compression algorithm is uploaded to the UDVM as part of the
	compressed data.		compressed data.
	The basic SigComp RFC describes the actions that an endpoint must		The basic SigComp RFC describes the actions that an endpoint must
	take upon receiving a SigComp message. However the entity		take upon receiving a SigComp message. However the entity
	responsible for generating new SigComp messages (the SigComp		responsible for generating new SigComp messages (the SigComp
	compressor) is left as an implementation decision; any compressor can		compressor) is left as an implementation decision; any compressor can
	be used provided that it generates SigComp messages that can be		be used provided that it generates SigComp messages that can be
	successfully decompressed by the receiving endpoint.		successfully decompressed by the receiving endpoint.
	This document offers a number of different compressors that can be		This document gives examples of a number of different compressors
	used by the SigComp protocol. It also gives examples of how to use		that can be used by the SigComp protocol. It also gives examples of
	some of the mechanisms (such as acknowledgements) described in RFC		how to use some of the mechanisms (such as acknowledgements)
	3321 [5].		described in RFC 3321 [5].
	2. Overview of the User Guide		2. Overview of the User Guide
	When implementing a SigComp compressor the first step is to choose a		When implementing a SigComp compressor the first step is to choose a
	compression algorithm that can encode the application messages into a		compression algorithm that can encode the application messages into a
	(hopefully) smaller form. Since SigComp can upload bytecode for new		(hopefully) smaller form. Since SigComp can upload bytecode for new
	algorithms to the receiving endpoint, arbitrary compression		algorithms to the receiving endpoint, arbitrary compression
	algorithms can be supported provided that bytecode has been written		algorithms can be supported provided that bytecode has been written
	for the corresponding decompressor.		for the corresponding decompressor.
	skipping to change at page 4, line 15 ¶		skipping to change at page 4, line 15 ¶
	The following robustness techniques and other mechanisms specific to		The following robustness techniques and other mechanisms specific to
	the SigComp environment are covered in this document:		the SigComp environment are covered in this document:
	1. Acknowledgements using the SigComp feedback mechanism		1. Acknowledgements using the SigComp feedback mechanism
	2. Static dictionary		2. Static dictionary
	3. CRC checksum		3. CRC checksum
	4. Announcing additional resources		4. Announcing additional resources
	5. Shared compression		5. Shared compression
	Any or all of the above mechanisms can be implemented in conjunction		Any or all of the above mechanisms can be implemented in conjunction
	with the chosen compression algorithm. A subroutine of UDVM bytecode		with the chosen compression algorithm. An example subroutine of UDVM
	is provided for each of the mechanisms; these subroutines can be		bytecode is provided for each of the mechanisms; these subroutines
	added to the bytecode for one of the basic compression algorithms.		can be added to the bytecode for one of the basic compression
			algorithms. (NB. The subroutine or the basic algorithm may require
			minor modification to ensure they work together correctly.)
	3. UDVM assembly language		3. UDVM assembly language
	Writing UDVM programs directly in bytecode would be a daunting task,		Writing UDVM programs directly in bytecode would be a daunting task,
	so a simple assembly language is provided to facilitate the creation		so a simple assembly language is provided to facilitate the creation
	of new decompression algorithms. The assembly language includes		of new decompression algorithms. The assembly language includes
	mnemonic codes for each of the UDVM instructions, as well as simple		mnemonic codes for each of the UDVM instructions, as well as simple
	directives for evaluating integer expressions, padding the bytecode		directives for evaluating integer expressions, padding the bytecode
	and so forth.		and so forth.
	skipping to change at page 8, line 42 ¶		skipping to change at page 8, line 42 ¶
	Since literal operands are used to indicate the total number of		Since literal operands are used to indicate the total number of
	operands for an instruction, it is possible to leave a literal		operands for an instruction, it is possible to leave a literal
	operand blank and allow its value to be inferred automatically by the		operand blank and allow its value to be inferred automatically by the
	assembler. For example:		assembler. For example:
	MULTILOAD (64, , 1, 2, 3, 4)		MULTILOAD (64, , 1, 2, 3, 4)
	The missing operand should be given the value 4 because it is		The missing operand should be given the value 4 because it is
	followed by a total of 4 operands.		followed by a total of 4 operands.
	If the operand is a reference then as per Figure 9 of SigComp, the		If the operand is a reference then, as per Figure 9 of SigComp, the
	parser inserts bytecode (ususally the shortest) capable of encoding		parser inserts bytecode (usually the shortest) capable of encoding
	the supplied memory address. Note that reference operands will		the supplied memory address. Note that reference operands will
	always be preceded by the symbol "$" in assembly because they always		always be preceded by the symbol "$" in assembly because they always
	encode memory addresses rather than actual operand values.		encode memory addresses rather than actual operand values.
	If the operand is a multitype then the parser first checks whether		If the operand is a multitype then the parser first checks whether
	the symbol "$" is present. If so then, as per Figure 10 of SigComp,		the symbol "$" is present. If so then, as per Figure 10 of SigComp,
	it inserts bytecode (usually the shortest) capable of encoding the		it inserts bytecode (usually the shortest) capable of encoding the
	supplied integer as a memory address. If not then, as per Figure 10		supplied integer as a memory address. If not then, as per Figure 10
	of SigComp, it inserts bytecode (usually the shortest) that encodes		of SigComp, it inserts bytecode (usually the shortest) that encodes
	the supplied integer as an operand value.		the supplied integer as an operand value.
	skipping to change at page 21, line 4 ¶		skipping to change at page 20, line 50 ¶
	; position/length pair:		; position/length pair:
	OUTPUT ($position_value, $length_value)		OUTPUT ($position_value, $length_value)
	JUMP (next_character)		JUMP (next_character)
	:end_of_message		:end_of_message
	END-MESSAGE (requested_feedback_location,		END-MESSAGE (requested_feedback_location,
	returned_parameters_location, state_length, 64,		returned_parameters_location, state_length, 64,
	decompress_sigcomp_message, 6, 0)		decompress_sigcomp_message, 6, 0)
	:static_dictionary pad (256)		:static_dictionary pad (256)
	:circular_buffer		:circular_buffer
	at (4492)		at (4492)
	:codebook		:codebook
	An example message compressed using the LZW algorithm is given below:		An example message compressed using the LZW algorithm is given below:
	0x14c6 f080 6c1b c6e1 9c20 1846 e190 201d 0684 206b 1cc2 0198 6f1c		0x14c6 f080 6c1b c6e1 9c20 1846 e190 201d 0684 206b 1cc2 0198 6f1c
	0x9071 b06c 42c6 8195 111a 4731 a021 02bf f0		0x9071 b06c 42c6 8195 111a 4731 a021 02bf f0
	The uncompressed message is "So long and thanks for all the fish!\n".		The uncompressed message is "So long and thanks for all the fish!\n".
	4.1.4 DEFLATE		4.1.4 DEFLATE
	This section provides UDVM bytecode for the DEFLATE compression		This section provides UDVM bytecode for the DEFLATE compression
	algorithm. DEFLATE is the algorithm used in the well-known "gzip"		algorithm. DEFLATE is the algorithm used in the well-known "gzip"
	file format.		file format.
	The following bytecode will decompress the DEFLATE compressed data		The following bytecode will decompress the DEFLATE compressed data
	format DEFLATE [10] with the following modifications:		format [10] with the following modifications:
	1. The DEFLATE compressed data format separates blocks of compressed		1. The DEFLATE compressed data format separates blocks of compressed
	data by transmitting 7 consecutive zero bits. Each SigComp		data by transmitting 7 consecutive zero bits. Each SigComp
	message is assumed to contain a separate block of compressed		message is assumed to contain a separate block of compressed
	data, so the end-of-block bits are implicit and do not need to be		data, so the end-of-block bits are implicit and do not need to be
	transmitted at the end of a SigComp message.		transmitted at the end of a SigComp message.
	2. This bytecode supports only DEFLATE block type 01 (data		2. This bytecode supports only DEFLATE block type 01 (data
	compressed with fixed Huffman codes).		compressed with fixed Huffman codes).
	Assembly for the DEFLATE decompressor is given below:		Assembly for the DEFLATE decompressor is given below:
	skipping to change at page 23, line 4 ¶		skipping to change at page 22, line 50 ¶
	2, 9, 2, 13, 3, 17,		2, 9, 2, 13, 3, 17,
	3, 25, 4, 33, 4, 49,		3, 25, 4, 33, 4, 49,
	5, 65, 5, 97, 6, 129,		5, 65, 5, 97, 6, 129,
	6, 193, 7, 257, 7, 385,		6, 193, 7, 257, 7, 385,
	8, 513, 8, 769, 9, 1025,		8, 513, 8, 769, 9, 1025,
	9, 1537, 10, 2049, 10, 3073,		9, 1537, 10, 2049, 10, 3073,
	11, 4097, 11, 6145, 12, 8193,		11, 4097, 11, 6145, 12, 8193,
	12, 12289, 13, 16385, 13, 24577)		12, 12289, 13, 16385, 13, 24577)
	:decompress_sigcomp_message		:decompress_sigcomp_message
	INPUT-BITS (3, extra_length_bits, !)
			INPUT-BITS (3, extra_length_bits, !)
	:next_character		:next_character
	INPUT-HUFFMAN (index, end_of_message, 4,		INPUT-HUFFMAN (index, end_of_message, 4,
	7, 0, 23, length_table_start,		7, 0, 23, length_table_start,
	1, 48, 191, 0,		1, 48, 191, 0,
	0, 192, 199, length_table_mid,		0, 192, 199, length_table_mid,
	1, 400, 511, 144)		1, 400, 511, 144)
	COMPARE ($index, length_table_start, literal, end_of_message,		COMPARE ($index, length_table_start, literal, end_of_message,
	length_distance)		length_distance)
	skipping to change at page 27, line 4 ¶		skipping to change at page 26, line 49 ¶
	MULTIPLY ($index, 3)		MULTIPLY ($index, 3)
	ADD ($index, first_codeword)		ADD ($index, first_codeword)
	COPY ($index, 3, length_value_lsb)		COPY ($index, 3, length_value_lsb)
	LOAD (current_length, 1)		LOAD (current_length, 1)
	ADD ($current_length, $length_value)		ADD ($current_length, $length_value)
	LOAD (codebook_old, $codebook_next)		LOAD (codebook_old, $codebook_next)
	COPY-LITERAL (current_length_lsb, 3, $codebook_next)		COPY-LITERAL (current_length_lsb, 3, $codebook_next)
	COPY-LITERAL ($position_value, $length_value, $decompressed_pointer)		COPY-LITERAL ($position_value, $length_value, $decompressed_pointer)
	OUTPUT ($position_value, $length_value)		OUTPUT ($position_value, $length_value)
	JUMP (prefix_after_codeword)		JUMP (prefix_after_codeword)
	:string_extension
			:string_extension
	; The following code decompresses a Huffman-encoded string extension:		; The following code decompresses a Huffman-encoded string extension:
	INPUT-HUFFMAN (index, !, 4, 1, 1, 1, 1, 2, 1, 3, 2, 1, 1, 1, 13, 3,		INPUT-HUFFMAN (index, !, 4, 1, 1, 1, 1, 2, 1, 3, 2, 1, 1, 1, 13, 3,
	0, 7, 5)		0, 7, 5)
	COMPARE ($index, 13, continue, extra_bits, extra_bits)		COMPARE ($index, 13, continue, extra_bits, extra_bits)
	:extra_bits		:extra_bits
	INPUT-BITS (max_extension_length, extra_extension_bits, !)		INPUT-BITS (max_extension_length, extra_extension_bits, !)
	ADD ($index, $extra_extension_bits)		ADD ($index, $extra_extension_bits)
	skipping to change at page 28, line 4 ¶		skipping to change at page 27, line 50 ¶
	INPUT-BYTES (0, 0, 0)		INPUT-BYTES (0, 0, 0)
	JUMP (standard_prefix)		JUMP (standard_prefix)
	:stepup		:stepup
	; The STEPUP control character increases the number of bits used to		; The STEPUP control character increases the number of bits used to
	; encode an ordinal value or a codeword:		; encode an ordinal value or a codeword:
	INPUT-BITS (1, index, !)		INPUT-BITS (1, index, !)
	COMPARE ($index, 1, stepup_ordinal, stepup_codeword, 0)		COMPARE ($index, 1, stepup_ordinal, stepup_codeword, 0)
	:stepup_ordinal
			:stepup_ordinal
	ADD ($ordinal_length, 1)		ADD ($ordinal_length, 1)
	JUMP (ordinal)		JUMP (ordinal)
	:stepup_codeword		:stepup_codeword
	ADD ($codeword_length, 1)		ADD ($codeword_length, 1)
	JUMP (codeword_control)		JUMP (codeword_control)
	:end_of_message		:end_of_message
	skipping to change at page 31, line 38 ¶		skipping to change at page 31, line 37 ¶
	The uncompressed message is "Arthur leapt to his feet like an author		The uncompressed message is "Arthur leapt to his feet like an author
	hearing the phone ring".		hearing the phone ring".
	5. Additional SigComp mechanisms		5. Additional SigComp mechanisms
	The following chapter covers the additional mechanisms that can be		The following chapter covers the additional mechanisms that can be
	employed by SigComp to improve the overall compression ratio;		employed by SigComp to improve the overall compression ratio;
	including the use of acknowledgements, dictionaries and sharing state		including the use of acknowledgements, dictionaries and sharing state
	between two directions of a compressed message flow.		between two directions of a compressed message flow.
	When each of the compression algorithms described in Chapter 4 has		Example assembly code is provided for these mechanisms. Depending on
			the mechanism and basic algorithm in use, the assembly code for
			either the mechanism or the basic algorithm may require modification
			(e.g. if the algorithm uses 'no more input' to jump to
			end_of_message, following end_of_message with an input instruction
			for CRC will not work). In any case, these are examples and there
			may be alternative ways to make use of the mechanisms.
			When each of the compression algorithms described in Section 4 has
	successfully decompressed the current SigComp message, the contents		successfully decompressed the current SigComp message, the contents
	of the UDVM memory are saved as a SigComp state item. Subsequent		of the UDVM memory are saved as a SigComp state item. Subsequent
	messages can access this state item by uploading the correct state		messages can access this state item by uploading the correct state
	identifier to the receiving endpoint, which avoids the need to upload		identifier to the receiving endpoint, which avoids the need to upload
	the bytecode for the compression algorithm on a per-message basis.		the bytecode for the compression algorithm on a per-message basis.
	However, before a state item can be accessed the compressor must		However, before a state item can be accessed the compressor must
	first ensure that it is available at the receiving endpoint.		first ensure that it is available at the receiving endpoint.
	For each SigComp compartment, the receiving endpoint maintains a list		For each SigComp compartment, the receiving endpoint maintains a list
	of currently available states (where the total amount of state saved		of currently available states (where the total amount of state saved
	does not exceed the state_memory_size for the compartment). The		does not exceed the state_memory_size for the compartment). The
	SigComp compressor should maintain a similar list containing the		SigComp compressor should maintain a similar list containing the
	states that it has instructed the receiving endpoint to save.		states that it has instructed the receiving endpoint to save.
	As well as tracking the list of state items that it has saved at the		As well as tracking the list of state items that it has saved at the
	skipping to change at page 33, line 47 ¶		skipping to change at page 34, line 7 ¶
	and SDP RFC-3485 [6]. This dictionary is designed for use by a wide		and SDP RFC-3485 [6]. This dictionary is designed for use by a wide
	range of compression algorithms including all of the ones covered in		range of compression algorithms including all of the ones covered in
	Chapter 4.		Chapter 4.
	In any of the compression algorithms of Chapter 4, the static		In any of the compression algorithms of Chapter 4, the static
	dictionary can be accessed by inserting the following instruction		dictionary can be accessed by inserting the following instruction
	immediately after the ":initialize_memory" label:		immediately after the ":initialize_memory" label:
	STATE-ACCESS (dictionary_id, 6, 0, 0, 1024, 0)		STATE-ACCESS (dictionary_id, 6, 0, 0, 1024, 0)
			The parameters of STATE-ACCESS instruction will depend on the
			compression algorithm in use.
	The following lines should also be inserted immediately after the		The following lines should also be inserted immediately after the
	END-MESSAGE instruction:		END-MESSAGE instruction:
	:dictionary_id		:dictionary_id
	byte (0xfb, 0xe5, 0x07, 0xdf, 0xe5, 0xe6)		byte (0xfb, 0xe5, 0x07, 0xdf, 0xe5, 0xe6)
	The text strings contained in the static dictionary can then be		The text strings contained in the static dictionary can then be
	accessed in exactly the same manner as the text strings from		accessed in exactly the same manner as the text strings from
	previously decompressed messages (see Section 5.1 for further		previously decompressed messages (see Section 5.1 for further
	details).		details).
	Note that in some cases it is sufficient to only load part of the		Note that in some cases it is sufficient to only load part of the
	static dictionary into the UDVM memory. Further information on the		static dictionary into the UDVM memory. Further information on the
	contents of the SIP and SDP static dictionary can be found in the		contents of the SIP and SDP static dictionary can be found in the
	relevant document RFC-3485 [6].		relevant document RFC-3485 [6].
	5.3 CRC checksum		5.3 CRC checksum
	Whilst the acknowledgement scheme of Section 5.1 is designed to		The acknowledgement scheme of Section 5.1 is designed to indicate the
	ensure that SigComp does not propagate errors introduced by the		successful decompression of a message. However, it does not
	underlying transport layer, in some cases it may be useful to add an		guarantee that the decompressed message is identical to the original
	extra CRC check over the UDVM memory. For example, if the transport		message, since decompression of a corrupted message could succeed but
	layer fails to discard a damaged SigComp message then a CRC check can		with some characters being incorrect. This could lead to an
	ensure that the corresponding decompressed message is not forwarded		incorrect message being passed to the application or unexpected
	to the application.		contents of state to be stored. In order to prevent this happening a
			CRC check could be used.
	If an additional CRC check is required then the following bytecode		If an additional CRC check is required then the following bytecode
	can be inserted after the ":end_of_message" label:		can be inserted after the ":end_of_message" label:
	INPUT-BYTES (2, index, !)		INPUT-BYTES (2, index, !)
	CRC ($index, 64, state_length, !)		CRC ($index, 64, state_length, !)
	The bytecode extracts a 2-byte CRC from the end of the SigComp		The bytecode extracts a 2-byte CRC from the end of the SigComp
	message and compares it with a CRC calculated over the UDVM memory.		message and compares it with a CRC calculated over the UDVM memory.
	Decompression failure occurs if the two CRC values do not match.		Decompression failure occurs if the two CRC values do not match.
	skipping to change at page 35, line 16 ¶		skipping to change at page 35, line 27 ¶
	useful for the remote endpoint to reference, it can advertise the		useful for the remote endpoint to reference, it can advertise the
	identifiers for the states. The remote endpoint can then make use of		identifiers for the states. The remote endpoint can then make use of
	any that it also knows about (i.e. knows the contents of) e.g. a		any that it also knows about (i.e. knows the contents of) e.g. a
	dictionary or shared mode state (see Section 5.5).		dictionary or shared mode state (see Section 5.5).
	The values of the following SigComp parameters can be announced using		The values of the following SigComp parameters can be announced using
	the SigComp advertisement mechanism:		the SigComp advertisement mechanism:
	cycles_per_bit		cycles_per_bit
	decompression_memory_size		decompression_memory_size
	state_memory_size>		state_memory_size
	SigComp_version		SigComp_version
	state identifiers		state identifiers
	As explained in SigComp, in order to announce the values of these		As explained in SigComp, in order to announce the values of these
	parameters the following fields must be reserved in the UDVM memory:		parameters the following fields must be reserved in the UDVM memory:
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+
	| cpb | dms | sms | returned_parameters_location		| cpb | dms | sms | returned_parameters_location
	+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+
	skipping to change at page 37, line 13 ¶		skipping to change at page 37, line 39 ¶
	Firstly, it is necessary to announce to the remote endpoint that		Firstly, it is necessary to announce to the remote endpoint that
	shared compression is available. This is done by announcing the		shared compression is available. This is done by announcing the
	state identifier as an available piece of state. This can be done		state identifier as an available piece of state. This can be done
	using the returned_parameters_location announcement as in		using the returned_parameters_location announcement as in
	Section 5.4.		Section 5.4.
	Secondly, assuming that such an announcement is received from the		Secondly, assuming that such an announcement is received from the
	remote endpoint, then the state created by shared compression needs		remote endpoint, then the state created by shared compression needs
	to be accessed by the message sent in the opposite direction. This		to be accessed by the message sent in the opposite direction. This
	can be done in a similar way to accessing the static dictionary (see		can be done in a similar way to accessing the static dictionary (see
	Section Section 5.2), but using the appropriate state identifier, for		Section 5.2), but using the appropriate state identifier, for
	example, by using the INPUT-BYTES instruction as below:		example, by using the INPUT-BYTES instruction as below:
	:shared_state_id pad (6)		:shared_state_id pad (6)
	:access_shared_state		:access_shared_state
	INPUT-BYTES (6, shared_state_id, !)		INPUT-BYTES (6, shared_state_id, !)
	STATE-ACCESS (shared_state_id, 6, 0, 0, $decompressed_start, 0)		STATE-ACCESS (shared_state_id, 6, 0, 0, $decompressed_start, 0)
	6. Security considerations		6. Security considerations
	skipping to change at page 42, line 50 ¶		skipping to change at page 42, line 50 ¶
	Copyright (C) The Internet Society (2005). This document is subject		Copyright (C) The Internet Society (2005). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
	This Internet-Draft will expire on April 1, 2006.		This Internet-Draft will expire on April 27, 2006.
End of changes. 24 change blocks.
	37 lines changed or deleted		53 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/