Skip to main content

Signaling Compression (SigComp) Corrections and Clarifications
draft-ietf-rohc-sigcomp-impl-guide-10

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    rohc mailing list <rohc@ietf.org>, 
    rohc chair <rohc-chairs@tools.ietf.org>
Subject: Protocol Action: 'Implementer's Guide for SigComp' to 
         Proposed Standard 

The IESG has approved the following document:

- 'Implementer's Guide for SigComp '
   <draft-ietf-rohc-sigcomp-impl-guide-11.txt> as a Proposed Standard

This document is the product of the Robust Header Compression Working 
Group. 

The IESG contact persons are Magnus Westerlund and Lars Eggert.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-impl-guide-11.txt

Ballot Text

Technical Summary

  This document describes common misinterpretations and some
  ambiguities in the Signalling Compression Protocol (SigComp), and
  offers guidance to developers to clarify any resultant problems.

Working Group Summary

  This document has grown through concerns from implementers. The
  final document has been reviewed by the WG, and there is WG
  consensus that the document should now be published as an RFC.

Document Quality

  There are several independent implementations of SigComp, which
  are in general already implemented according to this document.
 
Personnel
       
  Document Sheperd for this document is Lars-Erik Jonsson, and Magnus
  Westerlund is the Responsible Area Director.

Note to RFC Editor
 
First page header:

NEW:

Updates: RFC 3320, RFC 3321, RFC 3485 (once approved)

Title:

OLD:

 Implementer's Guide for SigComp

NEW:

 Signaling Compression (SigComp) Corrections and Clarifications


Abstract:

OLD:
This document (if approved) clarifies and corrects text in the
following updated RFCs: RFC 3320, RFC 3321, RFC 3485.

NEW:
This document updates the following RFCs: RFC 3320, RFC 3321, RFC 3485.

Section 1:
OLD:

      "in section 3.4" refers to section 3.4 of this document
      "in section RFC-3320:3.4 refers to section 3.4 of RFC 3320 [1]

NEW: 
      "in section 3.4" refers to section 3.4 of this document
      "in section RFC3320-3.4" refers to section 3.4 of RFC 3320 [1]

Section 2.1, First paragraph:

OLD:

   SigComp [1] states that the default Decompression Memory Size (DMS)
   is 2K. The UDVM memory size is defined in section RFC3320:7 to be
   (DMS - sizeof (sigcomp_msg)) for messages transported over UDP and
   (DMS / 2) for those transported over TCP.

NEW:

   SigComp [1] states that the default Decompression Memory Size (DMS)
   is 2K. The UDVM memory size is defined in section RFC3320-7 to be
   (DMS - sizeof (sigcomp_msg)) for messages transported over UDP and
   (DMS / 2) for those transported over TCP.


Section 12, final paragraph

OLD:
  These are seen to be relatively low cost bugs as only these 5 strings
  are affected and they are only affected under certain conditions.

NEW:
  This document does not correct the dictionary, as any changes to the
  dictionary itself would be non-backwards-compatible, and require all
  implementations to maintain two different copies of the dictionary.
  Such a cost is far too high for a bug that is trivial to work around
  and has negligible effect on compression ratios.  Instead, we point
  out the flaw so as to allow implementers to avoid any consequent
  problems.  Specifically: if the bytecodes sent to a remote endpoint
  contain instructions that load only a sub-portion of the SIP/SDP
  dictionary, then the input stream provided to those bytecodes cannot
  reference any of these five offsets in the offset table unless the
  corresponding string portion of the dictionary has also been loaded.
  For example, if bytecodes loaded only the first three priorities of
  the dictionary (both string and offset table), use of the offset for
  "send" (at 0x089d) would be valid; however, use of the offset for
  "phone" (at 0x00f2) would not.


Please replace all occurances of "Sigcomp" with "SigComp".

RFC Editor Note