[rohc] Making SigComp recognizable

"Dr. Carsten Bormann" <cabo@tzi.org> Tue, 26 February 2002 01:35 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05689 for <rohc-archive@odin.ietf.org>; Mon, 25 Feb 2002 20:35:34 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA29680; Mon, 25 Feb 2002 20:29:44 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA29632 for <rohc@optimus.ietf.org>; Mon, 25 Feb 2002 20:29:36 -0500 (EST)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05554 for <rohc@ietf.org>; Mon, 25 Feb 2002 20:29:09 -0500 (EST)
Received: from cabo3 (nmh.informatik.uni-bremen.de [134.102.224.3]) by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id g1Q1T4C10691 for <rohc@ietf.org>; Tue, 26 Feb 2002 02:29:04 +0100 (MET)
From: "Dr. Carsten Bormann" <cabo@tzi.org>
To: <rohc@ietf.org>
Subject: [rohc] Making SigComp recognizable
Date: Tue, 26 Feb 2002 02:29:03 +0100
Message-ID: <NFBBJFHGMCFINEMHAMBGCEIBHHAA.cabo@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Content-Transfer-Encoding: 7bit
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression <rohc.ietf.org>
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 7bit

In a phone conversation today, it occurred to us that it would be a good
idea to make SigComp packets clearly distinguishable from uncompressed
packets.
For SIP, this is easy, as all methods and reply codes are ASCII, so setting
the MSB in the first byte of all packets would suffice.
However, it's probably a good idea not to trigger the link-layer RTP ROHC
heuristics, which tend to look for 10xxxxxx in the first byte (RTP V=2) of
UDP packets.
More generally, I think we want to cater for general UTF-8-based signalling
protocols. Looking at RFC2044, we have:

   UCS-4 range (hex.)           UTF-8 octet sequence (binary)
   0000 0000-0000 007F   0xxxxxxx
   0000 0080-0000 07FF   110xxxxx 10xxxxxx
   0000 0800-0000 FFFF   1110xxxx 10xxxxxx 10xxxxxx

   0001 0000-001F FFFF   11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
   0020 0000-03FF FFFF   111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
   0400 0000-7FFF FFFF   1111110x 10xxxxxx ... 10xxxxxx

Now, since RFC2044 (October 1996), Unicode has been decided to stop at 0010
FFFF, so the code combinations

   0020 0000-03FF FFFF   111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
   0400 0000-7FFF FFFF   1111110x 10xxxxxx ... 10xxxxxx

never can appear in real UTF-8.

Leaping to a conclusion, it seems a SigComp/UDP packet should start with

	11111xxx

Sigcomp-04 uses 0xFF as an escape character, so xxx=111 should probably also
be avoided.
Alternatively, we could simply define a single byte distinguisher for UDP
and start all TCP streams with the escape sequence (and not use the UDP
distinguisher here).

Any other things we should avoid?  General comments on the whole approach?
(I just wish UDP had a protocol field.)

Gruesse, Carsten

PS.: Anyone for defining an RFC2246 (TLS) CompressionMethod value for
SigComp?
Should be fun, and would save the 0xFFFFs.
Can't even find an IANA registry for TLS, though.

PPS.: RFC2817 section 1 (motivation) is interesting reading.
Has anyone implemented that spec?
Could be done for SIP, too.




_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc