IETF Logo Mail Archive

RE: [rohc] RE: non-default capabilities

"Hans Hannu (EPL)" <Hans.Hannu@epl.ericsson.se> Wed, 20 February 2002 11:18 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 GAA26868 for <rohc-archive@odin.ietf.org>; Wed, 20 Feb 2002 06:18:30 -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 GAA17148; Wed, 20 Feb 2002 06:11:47 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17114 for <rohc@optimus.ietf.org>; Wed, 20 Feb 2002 06:11:44 -0500 (EST)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26811 for <rohc@ietf.org>; Wed, 20 Feb 2002 06:11:40 -0500 (EST)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g1KBBDhM013268 for <rohc@ietf.org>; Wed, 20 Feb 2002 12:11:13 +0100 (MET)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Feb 20 12:11:10 2002 +0100
Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <Z1HYS6HV>; Wed, 20 Feb 2002 12:10:21 +0100
Message-ID: <A943FD84BD9ED41193460008C791805003E9A27B@ESEALNT419.al.sw.ericsson.se>
From: "Hans Hannu (EPL)" <Hans.Hannu@epl.ericsson.se>
To: "'Lawrence Conroy'" <lwc@roke.co.uk>, rohc@ietf.org
Subject: RE: [rohc] RE: non-default capabilities
Date: Wed, 20 Feb 2002 12:10:44 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
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

Hi, 

The proposal that is somewhat described in SigComp and SigComp-extended is not exactly like the mechanism in SDP as this proposal can be interpreted as an explicit acknowledgement for an established state, which is one feature described in SigComp extended. Thus, a capability announcement mechanism including the reserved state identifiers for decompression algorithms, may also be used for other mechanisms in SigComp-extended. 

The IPR considerations chapter in SigComp-extended is there to notify that there might possible be IPRs related to the features described in that draft. Then it is up to the people who implement those feature to make the call whether they think that there may or may not be any IPRs on those features. But, please stop trying to convince people what to think about IPRs. If you do not think that there might possible be IPRs on a specific feature why do you not just go ahead and implement it.

>     Why the heck is sending a list of identifiers of 
> available decompression
> algorithms in the extended draft?

Well, that mechanism is not really in any of the drafts. The two drafts are not exactly fully compliant yet, but I'm working on this and will get a suggestion out to the list soon.

BR
/Hans H

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

v2.8.7 | Report a Bug | By Email