[rohc] TCP/IP EPIC profile

Julije Ozegovic <julije@fesb.hr> Tue, 26 February 2002 21:08 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 QAA21702 for <rohc-archive@odin.ietf.org>; Tue, 26 Feb 2002 16:08:44 -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 PAA19280; Tue, 26 Feb 2002 15:55:00 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19249 for <rohc@optimus.ietf.org>; Tue, 26 Feb 2002 15:54:57 -0500 (EST)
Received: from marjan.fesb.hr (root@marjan.fesb.hr [161.53.166.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21275 for <rohc@ietf.org>; Tue, 26 Feb 2002 15:54:45 -0500 (EST)
Received: (from root@localhost) by marjan.fesb.hr (8.9.3/8.9.3) id VAA03774 for rohc@ietf.org; Tue, 26 Feb 2002 21:54:39 +0100 (MET)
Received: from fesb.hr (demorgan.bit.fesb.hr [161.53.169.245]) by marjan.fesb.hr (8.9.3/8.9.3) with ESMTP id VAA03765 for <rohc@ietf.org>; Tue, 26 Feb 2002 21:54:31 +0100 (MET)
Message-ID: <3C7BF6E0.9070307@fesb.hr>
Date: Tue, 26 Feb 2002 21:58:08 +0100
From: Julije Ozegovic <julije@fesb.hr>
Organization: FESB Split
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en, hr
MIME-Version: 1.0
To: rohc <rohc@ietf.org>
Content-Type: multipart/mixed; boundary="------------060302020000080400000603"
X-Virus-Scanned: by AMaViS perl-11
Subject: [rohc] TCP/IP EPIC profile
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

Dear ROHCers,

here we include "expanded" TCP/IP profile as published in

TCP/IP Header Compression for ROHC (ROHC-TCP)
<draft-ietf-rohc-tcp-00.txt>

The purpose of this posting is to point out the complexity of 
whole thing, regarding the fact that almost every line of 
profile ends up with (at least) one data structure in end user 
application.

The questions are:
    do we really want this?
    do we really need this?
    is it worth the effort?
    is it applicable to target machine (GSM)?
    do we really need (48+2)*60=3000 formats?

Besides this, comments about inconsistencies of the profile are 
listed inline.

We also want to raise discussion about usage of FORMAT method.

The questions are:

    - what about difference in FORMAT structure
      between CO and IR/DYN packets,
      shouldn't they be the same (by EPIC draft)?

    - what about usage of IRREGULAR method in all sets
      (except last one where it should be used),
      this way first set will always be selected

    - what about syntax and usage of FORMAT SELECTOR,
      it is actually not needed (can be identified from
      ID-bits of IR/DYN packet)

Best regards,
Julije Ozegovic