RE: [rohc] Default decompression algorithms
"Price, Richard" <richard.price@roke.co.uk> Thu, 21 February 2002 14:28 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 JAA18223
for <rohc-archive@odin.ietf.org>; Thu, 21 Feb 2002 09:28:27 -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 JAA24438;
Thu, 21 Feb 2002 09:23:43 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24400
for <rohc@optimus.ietf.org>; Thu, 21 Feb 2002 09:23:36 -0500 (EST)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102])
by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18109
for <rohc@ietf.org>; Thu, 21 Feb 2002 09:23:31 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
id <1S9WNNBC>; Thu, 21 Feb 2002 14:21:43 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED4186F9FCE@rsys002a.roke.co.uk>
From: "Price, Richard" <richard.price@roke.co.uk>
To: "'Dr. Carsten Bormann'" <cabo@tzi.org>, "'Lars-Erik Jonsson (EPL)'"
<Lars-Erik.Jonsson@epl.ericsson.se>, "Conroy, Lawrence (SMTP)"
<lwc@roke.co.uk>
Cc: rohc@ietf.org
Subject: RE: [rohc] Default decompression algorithms
Date: Thu, 21 Feb 2002 14:21:42 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
boundary="------------InterScan_NT_MIME_Boundary"
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
> To me it seems the current draft is about twice as complex as it needs to be. > We need real time to fix all the small details in that complexity. > Complexity grows at least with some polynomial of the feature set. Hi Carsten, Is the additional complexity that you are worried about mainly due to the technical mechanisms of the draft, or the informative explanation of how the mechanisms can be used? There is quite a bit of the latter, and whilst it is very useful for implementers it is non-normative and could easily be omitted from the RFC. Perhaps we could shrink the size of the SigComp RFC by moving some of the text into a "SigComp implementer's guide" draft? This text could remain at draft status for now; we could put it into the SigComp RFC at a later stage (perhaps when we reach Draft Standard). If you believe that any technical mechanism could be omitted from SigComp without reducing the performance too badly then please let us know! > If we want to finish in time, we need to focus on removing, not about > adding. > > Since anybody can "profile" SigComp to include certain state ab initio, I > would like to propose that we end this discussion now. As you mention above, the mechanisms needed to provide algorithm negotiation are available already as part of the state reference mechanism. However, the reason that Lawrence began this discussion in the first place is as follows: [LWC] We have the facilities within SigComp to minimise or even remove the need for downloads, so the whacky contrib or three to the CN1 meeting is just a case of this group and CN1 being slightly out of phase. The "wacky contributions" were in fact proposals to add a separate algorithm negotiation mechanism externally to SigComp, despite the fact that one is already available within SigComp itself. More text is required somewhere to make this clear, although it is an implementation issue only and so does not need to be standardised as part of the base RFC for now. Regards, Richard
- [rohc] Default decompression algorithms Price, Richard
- RE: [rohc] Default decompression algorithms Abbie Barbir
- RE: [rohc] Default decompression algorithms Dr. Carsten Bormann
- [rohc] RE: Default decompression algorithms Lars-Erik Jonsson (EPL)
- RE: [rohc] Default decompression algorithms Price, Richard
- [rohc] RE: Default decompression algorithms Price, Richard
- RE: [rohc] Default decompression algorithms Price, Richard
- RE: [rohc] Default decompression algorithms Scott Bradner
- RE: [rohc] Default decompression algorithms Abbie Barbir
- Options (was: RE: [rohc] RE: Default decompressio… Dr. Carsten Bormann
- [rohc] RE: Default decompression algorithms Lars-Erik Jonsson (EPL)
- RE: [rohc] RE: Default decompression algorithms Dr. Carsten Bormann
- RE: [rohc] RE: Default decompression algorithms Abbie Barbir
- RE: [rohc] RE: Default decompression algorithms Lars-Erik Jonsson (EPL)
- RE: [rohc] RE: Default decompression algorithms zhigang.c.liu
- RE: [rohc] RE: Default decompression algorithms Dr. Carsten Bormann
- RE: [rohc] RE: Default decompression algorithms zhigang.c.liu
- Re: [rohc] RE: Default decompression algorithms Miguel A. Garcia
- RE: [rohc] RE: Default decompression algorithms Dr. Carsten Bormann
- Re: [rohc] RE: Default decompression algorithms Miguel A. Garcia
- RE: [rohc] RE: Default decompression algorithms zhigang.c.liu
- RE: [rohc] RE: Default decompression algorithms Dr. Carsten Bormann
- Re: [rohc] RE: Default decompression algorithms Miguel A. Garcia
- RE: [rohc] RE: Default decompression algorithms Dr. Carsten Bormann
- SigComp Requirements (was Re: [rohc] RE: Default … Miguel A. Garcia
- RE: SigComp Requirements (was Re: [rohc] RE: Defa… Dr. Carsten Bormann
- Re: SigComp Requirements (was Re: [rohc] RE: Defa… Miguel A. Garcia