From mailnull@www1.ietf.org  Thu Jan  2 03:52:35 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01176
	for <rohc-archive@odin.ietf.org>; Thu, 2 Jan 2003 03:52:35 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0290mB04807
	for rohc-archive@odin.ietf.org; Thu, 2 Jan 2003 04:00:48 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0290lJ04803
	for <rohc-web-archive@optimus.ietf.org>; Thu, 2 Jan 2003 04:00:47 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01167
	for <rohc-web-archive@ietf.org>; Thu, 2 Jan 2003 03:52:03 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0290aJ04787;
	Thu, 2 Jan 2003 04:00:36 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h028xgJ04721
	for <rohc@optimus.ietf.org>; Thu, 2 Jan 2003 03:59:42 -0500
Received: from web14805.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01161
	for <rohc@ietf.org>; Thu, 2 Jan 2003 03:50:58 -0500 (EST)
Message-ID: <20030102085409.47541.qmail@web14805.mail.yahoo.com>
Received: from [202.144.44.226] by web14805.mail.yahoo.com via HTTP; Thu, 02 Jan 2003 00:54:09 PST
Date: Thu, 2 Jan 2003 00:54:09 -0800 (PST)
From: Mahesh Govind <maheshgovind2002@yahoo.com>
To: rohc@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1929922222-1041497649=:47120"
Subject: [rohc] Compressed SIP Message
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

--0-1929922222-1041497649=:47120
Content-Type: text/plain; charset=us-ascii


Hi,

I am new to SigComp.Can any one give me an example of a compressed SIP message.

Thanks in advance.

Mahesh

 

 



---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
--0-1929922222-1041497649=:47120
Content-Type: text/html; charset=us-ascii

<P>Hi,</P>
<P>I am new to SigComp.Can any one give me an example of a compressed SIP message.</P>
<P>Thanks in advance.</P>
<P>Mahesh</P>
<P>&nbsp;</P>
<P>&nbsp;</P><p><br><hr size=1>Do you Yahoo!?<br>
<a href="http://rd.yahoo.com/mail/mailsig/*http://mailplus.yahoo.com">Yahoo! Mail Plus</a> - Powerful. Affordable. <a href="http://rd.yahoo.com/mail/mailsig/*http://mailplus.yahoo.com">Sign up now</a>
--0-1929922222-1041497649=:47120--
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Fri Jan  3 19:27:54 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22285
	for <rohc-archive@odin.ietf.org>; Fri, 3 Jan 2003 19:27:54 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h040as204034
	for rohc-archive@odin.ietf.org; Fri, 3 Jan 2003 19:36:54 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h040asJ04031
	for <rohc-web-archive@optimus.ietf.org>; Fri, 3 Jan 2003 19:36:54 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22280
	for <rohc-web-archive@ietf.org>; Fri, 3 Jan 2003 19:27:23 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h040aXJ04019;
	Fri, 3 Jan 2003 19:36:33 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h040YkJ03970
	for <rohc@optimus.ietf.org>; Fri, 3 Jan 2003 19:34:46 -0500
Received: from caduceus.fm.intel.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22271
	for <rohc@ietf.org>; Fri, 3 Jan 2003 19:25:15 -0500 (EST)
Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39])
	by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h040N9m10842
	for <rohc@ietf.org>; Sat, 4 Jan 2003 00:23:09 GMT
Received: from fmsmsxv040-1.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124])
	by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.27 2002/10/16 23:46:59 dmccart Exp $) with SMTP id h040H6W10924
	for <rohc@ietf.org>; Sat, 4 Jan 2003 00:17:06 GMT
Received: from fmsmsx331-2.fm.intel.com ([132.233.42.156])
 by fmsmsxv040-1.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003010316151911831
 for <rohc@ietf.org>; Fri, 03 Jan 2003 16:15:19 -0800
Received: from fmsmsx405.amr.corp.intel.com ([132.233.42.209]) by fmsmsx331-2.fm.intel.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Fri, 3 Jan 2003 16:14:57 -0800
content-class: urn:content-classes:message
Date: Fri, 3 Jan 2003 16:14:57 -0800
Message-ID: <AB4522133B886A46842423E3F032AD04BA3F25@fmsmsx405.fm.intel.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: CRC
X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0
Thread-Index: AcKzhlAjUjgYLeb3T9O27Wsqi0DhCQ==
From: "Sarkar, Rajib" <rajib.sarkar@intel.com>
To: <rohc@ietf.org>
X-OriginalArrivalTime: 04 Jan 2003 00:14:57.0556 (UTC) FILETIME=[5064AD40:01C2B386]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h040YkJ03971
Subject: [rohc] CRC
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Hi,
	Is there any code snippet for CRC calculation in C or C++.
Regards
Rajib

Rajib Sarkar
Ph No (310) 481 5709
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Mon Jan  6 02:03:00 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20137
	for <rohc-archive@odin.ietf.org>; Mon, 6 Jan 2003 02:03:00 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h067D5D22209
	for rohc-archive@odin.ietf.org; Mon, 6 Jan 2003 02:13:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h067D5J22191
	for <rohc-web-archive@optimus.ietf.org>; Mon, 6 Jan 2003 02:13:05 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19693
	for <rohc-web-archive@ietf.org>; Mon, 6 Jan 2003 02:02:26 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h067CnJ22008;
	Mon, 6 Jan 2003 02:12:50 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h067BLJ21659
	for <rohc@optimus.ietf.org>; Mon, 6 Jan 2003 02:11:21 -0500
Received: from fsnt.future.futsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18365
	for <rohc@ietf.org>; Mon, 6 Jan 2003 02:00:43 -0500 (EST)
Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com
 (Content Technologies SMTPRS 2.0.15) with ESMTP id <B0004089628@fsnt.future.futsoft.com> for <rohc@ietf.org>;
 Mon, 06 Jan 2003 12:38:37 +0530
Received: from ramanad (ramanad.future.futsoft.com [10.8.3.18])
	by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id h0671Gw0019890
	for <rohc@ietf.org>; Mon, 6 Jan 2003 12:31:16 +0530
Reply-To: <ramanad@future.futsoft.com>
From: "Ramana Divvi" <ramanad@future.futsoft.com>
To: <rohc@ietf.org>
Date: Mon, 6 Jan 2003 12:31:26 +0530
Message-Id: <001001c2b551$6eb30680$1203080a@future.futsoft.com>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
In-Reply-To: <A943FD84BD9ED41193460008C791805003E3246D@ESEALNT419.al.sw.ericsson.se>
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [rohc] Clarification regarding RFC2507
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi
In RFC2507, it is given that compressed non-TCP headers contains one BYTE
optional 'DATA' field.
If any one knows , please tell me what is the main purpose of this one Byte
DATA field.

Thanks in advance.

With Kind Regards,
Ramana.


***************************************************************************
This message is proprietary to Future Software Limited (FSL) 
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information 
and should not be circulated or used for any purpose other than for 
what it is intended. 

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. 
FSL accepts no responsibility for loss or damage arising from 
the use of the information transmitted by this email including
damage from virus.
***************************************************************************
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Mon Jan  6 18:39:30 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18872
	for <rohc-archive@odin.ietf.org>; Mon, 6 Jan 2003 18:39:30 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h06NnwU25419
	for rohc-archive@odin.ietf.org; Mon, 6 Jan 2003 18:49:58 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06NnvJ25416
	for <rohc-web-archive@optimus.ietf.org>; Mon, 6 Jan 2003 18:49:57 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18868
	for <rohc-web-archive@ietf.org>; Mon, 6 Jan 2003 18:38:37 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06NnLJ25392;
	Mon, 6 Jan 2003 18:49:22 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06NmVJ25378
	for <rohc@optimus.ietf.org>; Mon, 6 Jan 2003 18:48:31 -0500
Received: from gamma.isi.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18860;
	Mon, 6 Jan 2003 18:37:11 -0500 (EST)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87])
	by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h06NePD25520;
	Mon, 6 Jan 2003 15:40:25 -0800 (PST)
Message-Id: <200301062340.h06NePD25520@gamma.isi.edu>
To: IETF-Announce: ;
Cc: rfc-editor@rfc-editor.org, rohc@ietf.org
From: rfc-editor@rfc-editor.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Mon, 06 Jan 2003 15:40:25 -0800
Subject: [rohc] RFC 3320 on Signaling Compression (SigComp)
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>


--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 3320

        Title:      Signaling Compression (SigComp)
        Author(s):  R. Price, C. Bormann, J. Christoffersson,
                    H. Hannu, Z. Liu, J. Rosenberg
        Status:     Standards Track
        Date:       January 2003
        Mailbox:    richard.price@roke.co.uk, cabo@tzi.org,
                    jan.christoffersson@epl.ericsson.se,
                    hans.hannu@epl.ericsson.se
                    zhigang.c.liu@nokia.com, jdrosen@dynamicsoft.com
        Pages:      62
        Characters: 137035
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-rohc-sigcomp-07.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3320.txt


This document defines Signaling Compression (SigComp), a solution for
compressing messages generated by application protocols such as the
Session Initiation Protocol (SIP) (RFC 3261) and the Real Time
Streaming Protocol (RTSP) (RFC 2326).  The architecture and
prerequisites of SigComp are outlined, along with the format of the
SigComp message. 

Decompression functionality for SigComp is provided by a Universal
Decompressor Virtual Machine (UDVM) optimized for the task of running
decompression algorithms.  The UDVM can be configured to understand
the output of many well-known compressors such as DEFLATE (RFC-1951).

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

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="RFC-INFO@RFC-EDITOR.ORG"

Content-Type: text/plain
Content-ID: <030106153817.RFC@RFC-EDITOR.ORG>

RETRIEVE: rfc
DOC-ID: rfc3320

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3320.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <030106153817.RFC@RFC-EDITOR.ORG>

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



From mailnull@www1.ietf.org  Mon Jan  6 18:41:05 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18940
	for <rohc-archive@odin.ietf.org>; Mon, 6 Jan 2003 18:41:04 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h06NpWg25543
	for rohc-archive@odin.ietf.org; Mon, 6 Jan 2003 18:51:32 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06NpWJ25540
	for <rohc-web-archive@optimus.ietf.org>; Mon, 6 Jan 2003 18:51:32 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18920
	for <rohc-web-archive@ietf.org>; Mon, 6 Jan 2003 18:40:14 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06Np3J25497;
	Mon, 6 Jan 2003 18:51:03 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06NofJ25454
	for <rohc@optimus.ietf.org>; Mon, 6 Jan 2003 18:50:41 -0500
Received: from gamma.isi.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18877;
	Mon, 6 Jan 2003 18:39:32 -0500 (EST)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87])
	by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h06NglD26125;
	Mon, 6 Jan 2003 15:42:47 -0800 (PST)
Message-Id: <200301062342.h06NglD26125@gamma.isi.edu>
To: IETF-Announce: ;
Cc: rfc-editor@rfc-editor.org, rohc@ietf.org
From: rfc-editor@rfc-editor.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Mon, 06 Jan 2003 15:42:47 -0800
Subject: [rohc] RFC 3321 on Signaling Compression (SigComp) - Extended Operations
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>


--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 3321

        Title:      Signaling Compression (SigComp) - Extended
                    Operations
        Author(s):  H. Hannu, J. Christoffersson, S. Forsgren,
                    K. Leung, Z. Liu, R. Price
        Status:     Informational
        Date:       January 2003
        Mailbox:    hans.hannu@epl.ericsson.se,
                    jan.christoffersson@epl.ericsson.se,
                    StefanForsgren@alvishagglunds.se,
                    kcleung@eee.hku.hk, zhigang.c.liu@nokia.com,
                    richard.price@roke.co.uk 
        Pages:      19
        Characters: 39433
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-rohc-sigcomp-extended-04.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3321.txt


This document describes how to implement certain mechanisms in
Signaling Compression (SigComp), RFC 3320, which can significantly
improve the compression efficiency compared to using simple
per-message compression.

SigComp uses a Universal Decompressor Virtual Machine (UDVM) for
decompression, and the mechanisms described in this document are
possible to implement using the UDVM instructions defined in RFC 3320.

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

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="RFC-INFO@RFC-EDITOR.ORG"

Content-Type: text/plain
Content-ID: <030106154041.RFC@RFC-EDITOR.ORG>

RETRIEVE: rfc
DOC-ID: rfc3321

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3321.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <030106154041.RFC@RFC-EDITOR.ORG>

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



From mailnull@www1.ietf.org  Mon Jan  6 18:43:04 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18990
	for <rohc-archive@odin.ietf.org>; Mon, 6 Jan 2003 18:43:04 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h06NrWM25668
	for rohc-archive@odin.ietf.org; Mon, 6 Jan 2003 18:53:32 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06NrWJ25665
	for <rohc-web-archive@optimus.ietf.org>; Mon, 6 Jan 2003 18:53:32 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18976
	for <rohc-web-archive@ietf.org>; Mon, 6 Jan 2003 18:42:13 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06Nr1J25623;
	Mon, 6 Jan 2003 18:53:01 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06NqgJ25595
	for <rohc@optimus.ietf.org>; Mon, 6 Jan 2003 18:52:42 -0500
Received: from gamma.isi.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18957;
	Mon, 6 Jan 2003 18:41:30 -0500 (EST)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87])
	by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h06NiiD27438;
	Mon, 6 Jan 2003 15:44:44 -0800 (PST)
Message-Id: <200301062344.h06NiiD27438@gamma.isi.edu>
To: IETF-Announce: ;
Cc: rfc-editor@rfc-editor.org, rohc@ietf.org
From: rfc-editor@rfc-editor.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Mon, 06 Jan 2003 15:44:44 -0800
Subject: [rohc] RFC 3322 on Signaling Compression (SigComp) Requirements & Assumptions
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>


--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 3322

        Title:      Signaling Compression (SigComp) Requirements &
                    Assumptions
        Author(s):  H. Hannu
        Status:     Informational
        Date:       January 2003
        Mailbox:    hans.hannu@epl.ericsson.se
        Pages:      13
        Characters: 27533
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-rohc-signaling-req-assump-06.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3322.txt


The purpose of this document is to outline requirements and
motivations for the development of a scheme for compression and
decompression of messages from signaling protocols.  In wireless
environments and especially in cellular systems, e.g., GSM (Global
System for Mobile communications) and UMTS (Universal Mobile
Telecommunications System), there is a need to maximize the transport
efficiency for data over the radio interface.  With the introduction
of SIP/SDP (Session Initiation Protocol/Session Description Protocol)
to cellular devices, compression of the signaling messages should be
considered in order to improve both service availability and quality,
mainly by reducing the user idle time, e.g., at call setup.

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

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="RFC-INFO@RFC-EDITOR.ORG"

Content-Type: text/plain
Content-ID: <030106154302.RFC@RFC-EDITOR.ORG>

RETRIEVE: rfc
DOC-ID: rfc3322

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3322.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <030106154302.RFC@RFC-EDITOR.ORG>

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



From mailnull@www1.ietf.org  Tue Jan  7 03:01:55 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06520
	for <rohc-archive@odin.ietf.org>; Tue, 7 Jan 2003 03:01:55 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h078CVS32765
	for rohc-archive@odin.ietf.org; Tue, 7 Jan 2003 03:12:31 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h078CUJ32762
	for <rohc-web-archive@optimus.ietf.org>; Tue, 7 Jan 2003 03:12:30 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06510
	for <rohc-web-archive@ietf.org>; Tue, 7 Jan 2003 03:01:23 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h078CKJ32749;
	Tue, 7 Jan 2003 03:12:20 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h078BOJ32692
	for <rohc@optimus.ietf.org>; Tue, 7 Jan 2003 03:11:24 -0500
Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06482
	for <rohc@ietf.org>; Tue, 7 Jan 2003 03:00:16 -0500 (EST)
Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0783OAw026072;
	Tue, 7 Jan 2003 09:03:25 +0100 (MET)
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <ZGNBGHCA>; Tue, 7 Jan 2003 09:03:24 +0100
Message-ID: <A943FD84BD9ED41193460008C791805003E32493@ESEALNT419.al.sw.ericsson.se>
From: "Lars-Erik Jonsson (EAB)" <Lars-Erik.Jonsson@epl.ericsson.se>
To: "'ramanad@future.futsoft.com'" <ramanad@future.futsoft.com>, rohc@ietf.org
Subject: RE: [rohc] Clarification regarding RFC2507
Date: Tue, 7 Jan 2003 09:03:20 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Ramana,

Please see section 12 of RFC2507, "Hooks for additional header compression".

BR
/L-E


> -----Original Message-----
> From: Ramana Divvi [mailto:ramanad@future.futsoft.com]
> Sent: den 6 januari 2003 08:01
> To: rohc@ietf.org
> Subject: [rohc] Clarification regarding RFC2507
> 
> 
> Hi
> In RFC2507, it is given that compressed non-TCP headers 
> contains one BYTE
> optional 'DATA' field.
> If any one knows , please tell me what is the main purpose of 
> this one Byte
> DATA field.
> 
> Thanks in advance.
> 
> With Kind Regards,
> Ramana.
> 
> 
> **************************************************************
> *************
> This message is proprietary to Future Software Limited (FSL) 
> and is intended solely for the use of the individual to whom it
> is addressed. It may contain  privileged or confidential information 
> and should not be circulated or used for any purpose other than for 
> what it is intended. 
> 
> If you have received this message in error, please notify the
> originator immediately. If you are not the intended recipient,
> you are notified that you are strictly prohibited from using,
> copying, altering, or disclosing the contents of this message. 
> FSL accepts no responsibility for loss or damage arising from 
> the use of the information transmitted by this email including
> damage from virus.
> **************************************************************
> *************
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
> 
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Tue Jan  7 09:54:50 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15737
	for <rohc-archive@odin.ietf.org>; Tue, 7 Jan 2003 09:54:50 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h07F5YQ25957
	for rohc-archive@odin.ietf.org; Tue, 7 Jan 2003 10:05:34 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07F5YJ25954
	for <rohc-web-archive@optimus.ietf.org>; Tue, 7 Jan 2003 10:05:34 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15651
	for <rohc-web-archive@ietf.org>; Tue, 7 Jan 2003 09:54:18 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07F5JJ25939;
	Tue, 7 Jan 2003 10:05:19 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07F4IJ25838
	for <rohc@optimus.ietf.org>; Tue, 7 Jan 2003 10:04:18 -0500
Received: from fsnt.future.futsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15458
	for <rohc@ietf.org>; Tue, 7 Jan 2003 09:53:00 -0500 (EST)
Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com
 (Content Technologies SMTPRS 2.0.15) with ESMTP id <B0004105882@fsnt.future.futsoft.com> for <rohc@ietf.org>;
 Tue, 07 Jan 2003 20:30:48 +0530
Received: from gauravb (gauravb.future.futsoft.com [10.8.3.15])
	by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id h07ErPW4014429
	for <rohc@ietf.org>; Tue, 7 Jan 2003 20:23:25 +0530
Reply-To: <gauravb@future.futsoft.com>
From: "Gaurav Bhargava" <gauravb@future.futsoft.com>
To: "'rohc'" <rohc@ietf.org>
Date: Tue, 7 Jan 2003 20:26:43 +0530
Message-Id: <000001c2b65c$ff14e0c0$0f03080a@future.futsoft.com>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0001_01C2B68B.18DDE5A0"
Subject: [rohc] Genration incrementation in RFC 2507
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C2B68B.18DDE5A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Hello All,

I have a doubt regarding the generation value for Non TCP Header Compression
as per IPHC.
The RFC 2507 states that generation value is incremented “if the header
changes the context” in the compressor.

I understand the concept of streams for a Non TCP case is implementation
based. But if we take a normal case where for IP/UDP header I take all the
DEF fields to define a context and hence a stream. Meaning I take IP src,
dest addr, UDP src, dest ports as the fields which identify a context.

My question now is when one of these fields change, should I not go for a
change in CID ?

If so then in what scenarios do I increase the generation for a CID/Context
?

Thanks in advance.

Warm Regards,
Gaurav


***************************************************************************
This message is proprietary to Future Software Limited (FSL) 
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information 
and should not be circulated or used for any purpose other than for 
what it is intended. 

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. 
FSL accepts no responsibility for loss or damage arising from 
the use of the information transmitted by this email including
damage from virus.
***************************************************************************
------=_NextPart_000_0001_01C2B68B.18DDE5A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C2B68B.17D2DE40">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:View>Normal</w:View>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:9.0pt;
	mso-bidi-font-size:12.0pt;
	font-family:"Courier New";
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:9.0pt;
	mso-bidi-font-size:12.0pt;
	font-family:"Courier New";
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";}
span.EmailStyle15
	{mso-style-type:personal-compose;
	mso-ansi-font-size:10.0pt;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:black;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:35.4pt;
	mso-footer-margin:35.4pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
</head>

<body lang=3DEN-AU style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'>Hello All,<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'>I have a doubt regarding the generation value for Non TCP Header
Compression as per IPHC. <span style=3D"mso-spacerun: =
yes">&nbsp;</span><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'>The RFC 2507 states that generation value is incremented =
&#8220;if the header
changes the context&#8221; in the compressor. =
<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'>I understand the concept of streams for a Non TCP case is =
implementation
based. But if we take a normal case where for IP/UDP header I take all =
the DEF
fields to define a context and hence a stream. Meaning I take IP src, =
dest addr,
UDP src, dest ports as the fields which identify a =
context.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'>My question now is when one of these fields change, should I not =
go for a
change in CID ? <o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'>If so then in what scenarios do I increase the generation for a
CID/Context ?<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'>Thanks in advance.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'>Warm Regards,<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'>Gaurav<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'><span style=3D"mso-spacerun: yes">&nbsp;</span><span =
style=3D"mso-spacerun:
yes">&nbsp;</span><o:p></o:p></span></font></span></p>

</div>

</body>

</html>

------=_NextPart_000_0001_01C2B68B.18DDE5A0--

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



From mailnull@www1.ietf.org  Tue Jan  7 14:17:53 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25275
	for <rohc-archive@odin.ietf.org>; Tue, 7 Jan 2003 14:17:53 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h07JSjH11689
	for rohc-archive@odin.ietf.org; Tue, 7 Jan 2003 14:28:45 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07JSjJ11686
	for <rohc-web-archive@optimus.ietf.org>; Tue, 7 Jan 2003 14:28:45 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25229
	for <rohc-web-archive@ietf.org>; Tue, 7 Jan 2003 14:17:10 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07JSLJ11674;
	Tue, 7 Jan 2003 14:28:21 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07JRdJ11626
	for <rohc@optimus.ietf.org>; Tue, 7 Jan 2003 14:27:39 -0500
Received: from petasus.ch.intel.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25207
	for <rohc@ietf.org>; Tue, 7 Jan 2003 14:16:15 -0500 (EST)
Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129])
	by petasus.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.48 2002/10/16 23:47:34 dmccart Exp $) with SMTP id h07JKHe13185
	for <rohc@ietf.org>; Tue, 7 Jan 2003 19:20:17 GMT
Received: from fmsmsx331-2.fm.intel.com ([132.233.42.156])
 by fmsmsxvs043.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003010711173420873
 ; Tue, 07 Jan 2003 11:17:34 -0800
Received: from fmsmsx404.amr.corp.intel.com ([132.233.42.208]) by fmsmsx331-2.fm.intel.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 7 Jan 2003 11:19:30 -0800
content-class: urn:content-classes:message
Subject: RE: [rohc] Genration incrementation in RFC 2507
Date: Tue, 7 Jan 2003 11:19:29 -0800
Message-ID: <348846432D5298448844D13BE8C9636A70678A@fmsmsx404.fm.intel.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2B681.B366EC74"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0
Thread-Topic: [rohc] Genration incrementation in RFC 2507
Thread-Index: AcK2XRrqZ+GPOCJPEde/HABQi2jWFgAIl57w
From: "Dintakurthi, Satyanarayana V" <satyanarayana.v.dintakurthi@intel.com>
To: <gauravb@future.futsoft.com>, "rohc" <rohc@ietf.org>
X-OriginalArrivalTime: 07 Jan 2003 19:19:30.0190 (UTC) FILETIME=[B3B64AE0:01C2B681]
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C2B681.B366EC74
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Gaurav,

Please see my answers below.

=20

-----Original Message-----
From: Gaurav Bhargava [mailto:gauravb@future.futsoft.com]=20
Sent: Tuesday, January 07, 2003 6:57 AM
To: 'rohc'
Subject: [rohc] Genration incrementation in RFC 2507

=20

Hello All,

=20

I have a doubt regarding the generation value for Non TCP Header =
Compression as per IPHC. =20

The RFC 2507 states that generation value is incremented "if the header =
changes the context" in the compressor.=20

=20

I understand the concept of streams for a Non TCP case is implementation =
based. But if we take a normal case where for IP/UDP header I take all =
the DEF fields to define a context and hence a stream. Meaning I take IP =
src, dest addr, UDP src, dest ports as the fields which identify a =
context.

=20

My question now is when one of these fields change, should I not go for =
a change in CID ?=20

When the DEF fields change, it is a different packet stream and hence =
the CID changes.

=20

If so then in what scenarios do I increase the generation for a =
CID/Context ?

There are a few cases in the RFC, in which the generation value is =
incremented, but the CID remains the same.

One situation is, when any of the NOCHANGE field which is not part of =
the DEF changes, the generation value is incremented to indicate the new =
version of the context. There could be other situations like this =
mentioned in the RFC.

=20

=20

Thanks in advance.

=20

Warm Regards,

Gaurav

 =20

Any other comments on this are welcome.

Regards,

Satya

=20


------_=_NextPart_001_01C2B681.B366EC74
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:9.0pt;
	font-family:"Courier New";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:9.0pt;
	font-family:"Courier New";}
span.EmailStyle16
	{font-family:Arial;
	color:black;}
span.EmailStyle19
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi Gaurav,</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Please see my answers =
below.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Gaurav Bhargava
[mailto:gauravb@future.futsoft.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> </span></font><font =
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>Tuesday,
 January 07, 2003</span></font><font size=3D2 face=3DTahoma><span =
style=3D'font-size:
10.0pt;font-family:Tahoma'> </span></font><font size=3D2 =
face=3DTahoma><span
 style=3D'font-size:10.0pt;font-family:Tahoma'>6:57 =
AM</span></font><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'><br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'rohc'<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> [rohc] Genration
incrementation in RFC 2507</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D1 =
face=3D"Courier New">&nbsp;</font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span =
class=3DEmailStyle16><font
size=3D2 color=3Dblack face=3DArial><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>Hello
All,</span></font></span></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span =
class=3DEmailStyle16><font
size=3D2 color=3Dblack face=3DArial><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>&nbsp;</span></font></span></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span =
class=3DEmailStyle16><font
size=3D2 color=3Dblack face=3DArial><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>I have
a doubt regarding the generation value for Non TCP Header Compression as =
per
IPHC.=A0 </span></font></span></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span =
class=3DEmailStyle16><font
size=3D2 color=3Dblack face=3DArial><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>The RFC
2507 states that generation value is incremented &#8220;if the header =
changes
the context&#8221; in the compressor. </span></font></span></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span =
class=3DEmailStyle16><font
size=3D2 color=3Dblack face=3DArial><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>&nbsp;</span></font></span></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span =
class=3DEmailStyle16><font
size=3D2 color=3Dblack face=3DArial><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>I
understand the concept of streams for a Non TCP case is implementation =
based.
But if we take a normal case where for IP/UDP header I take all the DEF =
fields
to define a context and hence a stream. Meaning I take IP src, dest =
addr, UDP
src, dest ports as the fields which identify a =
context.</span></font></span></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span =
class=3DEmailStyle16><font
size=3D2 color=3Dblack face=3DArial><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>&nbsp;</span></font></span></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span =
class=3DEmailStyle16><font
size=3D2 color=3Dblack face=3DArial><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>My
question now is when one of these fields change, should I not go for a =
change
in CID ? </span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
lang=3DEN-AU style=3D'font-size:10.0pt;color:navy'>When the DEF fields =
change, it
is a different packet stream and hence the CID =
changes.</span></font></span></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span =
class=3DEmailStyle16><font
size=3D2 color=3Dblack face=3DArial><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>&nbsp;</span></font></span></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span =
class=3DEmailStyle16><font
size=3D2 color=3Dblack face=3DArial><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>If so
then in what scenarios do I increase the generation for a CID/Context =
?</span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
lang=3DEN-AU style=3D'font-size:10.0pt;color:navy'>There are a few cases =
in the
RFC, in which the generation value is incremented, but the CID remains =
the
same.</span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
lang=3DEN-AU style=3D'font-size:10.0pt;color:navy'>One situation is, =
when any of
the NOCHANGE field which is not part of the DEF changes, the generation =
value
is incremented to indicate the new version of the context. There could =
be other
situations like this mentioned in the RFC.</span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
lang=3DEN-AU =
style=3D'font-size:10.0pt;color:navy'>&nbsp;</span></font></span></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span =
class=3DEmailStyle16><font
size=3D2 color=3Dblack face=3DArial><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>&nbsp;</span></font></span></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span =
class=3DEmailStyle16><font
size=3D2 color=3Dblack face=3DArial><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>Thanks
in advance.</span></font></span></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span =
class=3DEmailStyle16><font
size=3D2 color=3Dblack face=3DArial><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>&nbsp;</span></font></span></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span =
class=3DEmailStyle16><font
size=3D2 color=3Dblack face=3DArial><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>Warm
Regards,</span></font></span></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span =
class=3DEmailStyle16><font
size=3D2 color=3Dblack face=3DArial><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>Gaurav</span></font></span></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span =
class=3DEmailStyle16><font
size=3D2 color=3Dblack face=3DArial><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>=A0 </span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
lang=3DEN-AU style=3D'font-size:10.0pt;color:navy'>Any other comments on =
this are
welcome.</span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
lang=3DEN-AU =
style=3D'font-size:10.0pt;color:navy'>Regards,</span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
lang=3DEN-AU =
style=3D'font-size:10.0pt;color:navy'>Satya</span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
lang=3DEN-AU =
style=3D'font-size:10.0pt;color:navy'>&nbsp;</span></font></span></p>

</div>

</body>

</html>
=00
------_=_NextPart_001_01C2B681.B366EC74--
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Wed Jan  8 00:32:47 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15170
	for <rohc-archive@odin.ietf.org>; Wed, 8 Jan 2003 00:32:47 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h085hoq16005
	for rohc-archive@odin.ietf.org; Wed, 8 Jan 2003 00:43:50 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h085hoJ16002
	for <rohc-web-archive@optimus.ietf.org>; Wed, 8 Jan 2003 00:43:50 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15149
	for <rohc-web-archive@ietf.org>; Wed, 8 Jan 2003 00:31:19 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h085gZJ15959;
	Wed, 8 Jan 2003 00:42:35 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h085fdJ15926
	for <rohc@optimus.ietf.org>; Wed, 8 Jan 2003 00:41:39 -0500
Received: from fsnt.future.futsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15106
	for <rohc@ietf.org>; Wed, 8 Jan 2003 00:30:01 -0500 (EST)
Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com
 (Content Technologies SMTPRS 2.0.15) with ESMTP id <B0004111196@fsnt.future.futsoft.com>;
 Wed, 08 Jan 2003 11:07:41 +0530
Received: from gauravb (gauravb.future.futsoft.com [10.8.3.15])
	by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id h085UHW4021874;
	Wed, 8 Jan 2003 11:00:17 +0530
Reply-To: <gauravb@future.futsoft.com>
From: "Gaurav Bhargava" <gauravb@future.futsoft.com>
To: "'Dintakurthi, Satyanarayana V'" <satyanarayana.v.dintakurthi@intel.com>,
        "'rohc'" <rohc@ietf.org>
Subject: RE: [rohc] Genration incrementation in RFC 2507
Date: Wed, 8 Jan 2003 11:03:38 +0530
Message-Id: <000a01c2b6d7$7f8a7740$0f03080a@future.futsoft.com>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <348846432D5298448844D13BE8C9636A70678A@fmsmsx404.fm.intel.com>
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000B_01C2B705.994BDB00"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_000B_01C2B705.994BDB00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Thanks Satya.
I got the point.

Warm Regards,
Gaurav
-----Original Message-----
From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of
Dintakurthi, Satyanarayana V
Sent: Wednesday, 8 January 2003 12:49 AM
To: gauravb@future.futsoft.com; rohc
Subject: RE: [rohc] Genration incrementation in RFC 2507

Hi Gaurav,
Please see my answers below.

-----Original Message-----
From: Gaurav Bhargava [mailto:gauravb@future.futsoft.com]
Sent: Tuesday, January 07, 2003 6:57 AM
To: 'rohc'
Subject: [rohc] Genration incrementation in RFC 2507

Hello All,

I have a doubt regarding the generation value for Non TCP Header Compression
as per IPHC.
The RFC 2507 states that generation value is incremented “if the header
changes the context” in the compressor.

I understand the concept of streams for a Non TCP case is implementation
based. But if we take a normal case where for IP/UDP header I take all the
DEF fields to define a context and hence a stream. Meaning I take IP src,
dest addr, UDP src, dest ports as the fields which identify a context.

My question now is when one of these fields change, should I not go for a
change in CID ?
When the DEF fields change, it is a different packet stream and hence the
CID changes.

If so then in what scenarios do I increase the generation for a CID/Context
?
There are a few cases in the RFC, in which the generation value is
incremented, but the CID remains the same.
One situation is, when any of the NOCHANGE field which is not part of the
DEF changes, the generation value is incremented to indicate the new version
of the context. There could be other situations like this mentioned in the
RFC.


Thanks in advance.

Warm Regards,
Gaurav

Any other comments on this are welcome.
Regards,
Satya


***************************************************************************
This message is proprietary to Future Software Limited (FSL) 
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information 
and should not be circulated or used for any purpose other than for 
what it is intended. 

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. 
FSL accepts no responsibility for loss or damage arising from 
the use of the information transmitted by this email including
damage from virus.
***************************************************************************
------=_NextPart_000_000B_01C2B705.994BDB00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C2B705.9860DEC0">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:16792199 0 0 0 65791 0;}
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:9.0pt;
	font-family:"Courier New";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:9.0pt;
	font-family:"Courier New";
	mso-fareast-font-family:"Times New Roman";}
span.emailstyle16
	{mso-style-name:emailstyle16;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:black;}
span.emailstyle19
	{mso-style-name:emailstyle19;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	mso-ansi-font-size:10.0pt;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:35.4pt;
	mso-footer-margin:35.4pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
</head>

<body lang=3DEN-AU link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle20><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:9.0pt;font-family:Arial'>Tha=
nks Satya.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle20><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:9.0pt;font-family:Arial'>I =
got the point.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle20><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:9.0pt;font-family:Arial'><![=
if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle20><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:9.0pt;font-family:Arial'>War=
m Regards,<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle20><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:9.0pt;font-family:Arial'>Gau=
rav<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DTahoma><span =
style=3D'font-size:
10.0pt;font-family:Tahoma;color:black'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> rohc-admin@ietf.org
[mailto:rohc-admin@ietf.org]<b><span style=3D'font-weight:bold'>On =
Behalf Of </span></b>Dintakurthi,
Satyanarayana V<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, 8 =
January 2003
12:49 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
gauravb@future.futsoft.com;
rohc<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: [rohc] =
Genration
incrementation in RFC 2507</span></font></p>

<p class=3DMsoNormal><font size=3D1 face=3D"Courier New"><span =
style=3D'font-size:9.0pt'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;color:navy;mso-ansi-language:=
EN-US'>Hi
Gaurav,</span></font><font color=3Dblack><span lang=3DEN-US =
style=3D'color:black;
mso-color-alt:windowtext;mso-ansi-language:EN-US'><o:p></o:p></span></fon=
t></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;color:navy;mso-ansi-language:=
EN-US'>Please
see my answers below.</span></font><font color=3Dblack><span =
lang=3DEN-US
style=3D'color:black;mso-color-alt:windowtext;mso-ansi-language:EN-US'><o=
:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;color:navy;mso-ansi-language:=
EN-US'>&nbsp;</span></font><font
color=3Dblack><span lang=3DEN-US =
style=3D'color:black;mso-color-alt:windowtext;
mso-ansi-language:EN-US'><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dblack
face=3DTahoma><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Tahoma;
color:black;mso-ansi-language:EN-US'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Gaurav Bhargava
[mailto:gauravb@future.futsoft.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, January =
07, 2003
6:57 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'rohc'<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> [rohc] Genration
incrementation in RFC 2507</span></font><font color=3Dblack><span =
lang=3DEN-US
style=3D'color:black;mso-color-alt:windowtext;mso-ansi-language:EN-US'><o=
:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D1 =
color=3Dblack
face=3D"Courier New"><span lang=3DEN-US =
style=3D'font-size:7.5pt;color:black;
mso-ansi-language:EN-US'>&nbsp;</span></font><font color=3Dblack><span
lang=3DEN-US =
style=3D'color:black;mso-color-alt:windowtext;mso-ansi-language:EN-US'><o=
:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><span =
class=3Demailstyle16><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Hello
All,</span></font></span><font color=3Dblack><span lang=3DEN-US =
style=3D'color:black;
mso-color-alt:windowtext;mso-ansi-language:EN-US'><o:p></o:p></span></fon=
t></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><span =
class=3Demailstyle16><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>&nbsp;</span></font></span><=
font
color=3Dblack><span lang=3DEN-US =
style=3D'color:black;mso-color-alt:windowtext;
mso-ansi-language:EN-US'><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><span =
class=3Demailstyle16><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>I
have a doubt regarding the generation value for Non TCP Header =
Compression as
per IPHC.&nbsp; </span></font></span><font color=3Dblack><span =
lang=3DEN-US
style=3D'color:black;mso-color-alt:windowtext;mso-ansi-language:EN-US'><o=
:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><span =
class=3Demailstyle16><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>The
RFC 2507 states that generation value is incremented &#8220;if the =
header changes the
context&#8221; in the compressor. </span></font></span><font =
color=3Dblack><span
lang=3DEN-US =
style=3D'color:black;mso-color-alt:windowtext;mso-ansi-language:EN-US'><o=
:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><span =
class=3Demailstyle16><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>&nbsp;</span></font></span><=
font
color=3Dblack><span lang=3DEN-US =
style=3D'color:black;mso-color-alt:windowtext;
mso-ansi-language:EN-US'><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><span =
class=3Demailstyle16><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>I
understand the concept of streams for a Non TCP case is implementation =
based.
But if we take a normal case where for IP/UDP header I take all the DEF =
fields
to define a context and hence a stream. Meaning I take IP src, dest =
addr, UDP
src, dest ports as the fields which identify a =
context.</span></font></span><font
color=3Dblack><span lang=3DEN-US =
style=3D'color:black;mso-color-alt:windowtext;
mso-ansi-language:EN-US'><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><span =
class=3Demailstyle16><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>&nbsp;</span></font></span><=
font
color=3Dblack><span lang=3DEN-US =
style=3D'color:black;mso-color-alt:windowtext;
mso-ansi-language:EN-US'><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><span =
class=3Demailstyle16><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>My
question now is when one of these fields change, should I not go for a =
change
in CID ? </span></font></span><font color=3Dblack><span lang=3DEN-US
style=3D'color:black;mso-color-alt:windowtext;mso-ansi-language:EN-US'><o=
:p></o:p></span></font></p>

<p class=3DMsoNormal><span class=3Demailstyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>When the DEF =
fields
change, it is a different packet stream and hence the CID =
changes.</span></font></span><font
color=3Dblack><span lang=3DEN-US =
style=3D'color:black;mso-color-alt:windowtext;
mso-ansi-language:EN-US'><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><span =
class=3Demailstyle16><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>&nbsp;</span></font></span><=
font
color=3Dblack><span lang=3DEN-US =
style=3D'color:black;mso-color-alt:windowtext;
mso-ansi-language:EN-US'><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><span =
class=3Demailstyle16><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>If
so then in what scenarios do I increase the generation for a CID/Context =
?</span></font></span><font
color=3Dblack><span lang=3DEN-US =
style=3D'color:black;mso-color-alt:windowtext;
mso-ansi-language:EN-US'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><span class=3Demailstyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>There are a few =
cases in
the RFC, in which the generation value is incremented, but the CID =
remains the
same.</span></font></span><font color=3Dblack><span lang=3DEN-US =
style=3D'color:black;
mso-color-alt:windowtext;mso-ansi-language:EN-US'><o:p></o:p></span></fon=
t></p>

<p class=3DMsoNormal><span class=3Demailstyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>One situation =
is, when
any of the NOCHANGE field which is not part of the DEF changes, the =
generation
value is incremented to indicate the new version of the context. There =
could be
other situations like this mentioned in the =
RFC.</span></font></span><font
color=3Dblack><span lang=3DEN-US =
style=3D'color:black;mso-color-alt:windowtext;
mso-ansi-language:EN-US'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><span class=3Demailstyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&nbsp;</span></fo=
nt></span><font
color=3Dblack><span lang=3DEN-US =
style=3D'color:black;mso-color-alt:windowtext;
mso-ansi-language:EN-US'><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><span =
class=3Demailstyle16><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>&nbsp;</span></font></span><=
font
color=3Dblack><span lang=3DEN-US =
style=3D'color:black;mso-color-alt:windowtext;
mso-ansi-language:EN-US'><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><span =
class=3Demailstyle16><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Thanks
in advance.</span></font></span><font color=3Dblack><span lang=3DEN-US
style=3D'color:black;mso-color-alt:windowtext;mso-ansi-language:EN-US'><o=
:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><span =
class=3Demailstyle16><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>&nbsp;</span></font></span><=
font
color=3Dblack><span lang=3DEN-US =
style=3D'color:black;mso-color-alt:windowtext;
mso-ansi-language:EN-US'><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><span =
class=3Demailstyle16><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Warm
Regards,</span></font></span><font color=3Dblack><span lang=3DEN-US
style=3D'color:black;mso-color-alt:windowtext;mso-ansi-language:EN-US'><o=
:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><span =
class=3Demailstyle16><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Gaurav</span></font></span><=
font
color=3Dblack><span lang=3DEN-US =
style=3D'color:black;mso-color-alt:windowtext;
mso-ansi-language:EN-US'><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><span =
class=3Demailstyle16><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>&nbsp;
</span></font></span><font color=3Dblack><span lang=3DEN-US =
style=3D'color:black;
mso-color-alt:windowtext;mso-ansi-language:EN-US'><o:p></o:p></span></fon=
t></p>

<p class=3DMsoNormal><span class=3Demailstyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Any other =
comments on
this are welcome.</span></font></span><font color=3Dblack><span =
lang=3DEN-US
style=3D'color:black;mso-color-alt:windowtext;mso-ansi-language:EN-US'><o=
:p></o:p></span></font></p>

<p class=3DMsoNormal><span class=3Demailstyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Regards,</span></=
font></span><font
color=3Dblack><span lang=3DEN-US =
style=3D'color:black;mso-color-alt:windowtext;
mso-ansi-language:EN-US'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><span class=3Demailstyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Satya</span></fon=
t></span><font
color=3Dblack><span lang=3DEN-US =
style=3D'color:black;mso-color-alt:windowtext;
mso-ansi-language:EN-US'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><span class=3Demailstyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&nbsp;</span></fo=
nt></span><font
color=3Dblack><span lang=3DEN-US =
style=3D'color:black;mso-color-alt:windowtext;
mso-ansi-language:EN-US'><o:p></o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_000B_01C2B705.994BDB00--

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



From mailnull@www1.ietf.org  Fri Jan 10 06:28:57 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24891
	for <rohc-archive@odin.ietf.org>; Fri, 10 Jan 2003 06:28:57 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0ABf5V23727
	for rohc-archive@odin.ietf.org; Fri, 10 Jan 2003 06:41:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ABf5J23724
	for <rohc-web-archive@optimus.ietf.org>; Fri, 10 Jan 2003 06:41:05 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24848
	for <rohc-web-archive@ietf.org>; Fri, 10 Jan 2003 06:28:15 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ABedJ23703;
	Fri, 10 Jan 2003 06:40:40 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ABdpJ23627
	for <rohc@optimus.ietf.org>; Fri, 10 Jan 2003 06:39:51 -0500
Received: from igate2.vodafone.co.uk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24820
	for <rohc@ietf.org>; Fri, 10 Jan 2003 06:27:12 -0500 (EST)
Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id LAA10677; Fri, 10 Jan 2003 11:30:28 GMT
Received: from putney.vfl.vodafone (putney [10.33.112.118])
	by mailguard2 (4.6.1.123) with ESMTP id 
	for <rohc@ietf.org>; Fri, 10 Jan 2003 11:26:40 GMT
Received: from ukwmxc02.vf-uk.internal.vodafone.com ([10.33.126.170]) by putney.vfl.vodafone with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id YL9AH85F; Fri, 10 Jan 2003 11:29:20 -0000
Received: from ukwmxc03.vf-uk.internal.vodafone.com ([10.33.126.155]) by ukwmxc02.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.4453);
	 Fri, 10 Jan 2003 11:28:40 +0000
Received: from ukwmxm01.vf-uk.internal.vodafone.com ([10.33.126.162]) by ukwmxc03.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.4453);
	 Fri, 10 Jan 2003 11:28:40 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
Date: Fri, 10 Jan 2003 11:28:40 -0000
Message-ID: <6FC554FA1F33BE4C9AC844FC3B3B71280D1461@UKWMXM01>
Thread-Topic: Question about R-Mode and packet types
Thread-Index: AcK4m6Huvo9RiCRyEdebOQBQBFRDqA==
From: "Holmes, Matthew, CND Tech Dev, VF UK" <Matthew.Holmes@gb.vodafone.co.uk>
To: <rohc@ietf.org>
X-OriginalArrivalTime: 10 Jan 2003 11:28:40.0591 (UTC) FILETIME=[6CE0D1F0:01C2B89B]
MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122)
Content-Type: text/plain;	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0ABdqJ23628
Subject: [rohc] Question about R-Mode and packet types
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Hi All

I'm a little confused with the following description in RFC 3095 section 5.5.1.2 where an example of an algorithm to update packets is given:

Let pRTT be the number of packets that are sent during one round-trip time. In the SO state, when (64 - pRTT) headers have been sent since the last acked reference, the compressor will send m1 consecutive R-0-CRC headers, then send (pRTT - m1) R-0 headers. After these headers have been sent, if the compressor has not received an ACK to at least one of the previously sent R0-CRC, it sends R-0-CRC headers continuously until it receives a corresponding ACK. m1 is an implementation parameter, which can be as large as pRTT.

I understand it up until the part when it says that if no ACK has been received R-0-CRC packets will be continuously sent. At some point though surely the compressor will have to start sending type 2 packets to included a larger SN. With the last ACKed reference number which the compressor has stored the SN in the R-0-CRC packet will become to small.

Any help clarifying the above would be much appreciated,

Thank you

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



From mailnull@www1.ietf.org  Fri Jan 10 06:44:18 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25430
	for <rohc-archive@odin.ietf.org>; Fri, 10 Jan 2003 06:44:18 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0ABuQa24360
	for rohc-archive@odin.ietf.org; Fri, 10 Jan 2003 06:56:26 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ABuQJ24357
	for <rohc-web-archive@optimus.ietf.org>; Fri, 10 Jan 2003 06:56:26 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25413
	for <rohc-web-archive@ietf.org>; Fri, 10 Jan 2003 06:43:36 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ABu7J24330;
	Fri, 10 Jan 2003 06:56:07 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ABtSJ24296
	for <rohc@optimus.ietf.org>; Fri, 10 Jan 2003 06:55:28 -0500
Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25391
	for <rohc@ietf.org>; Fri, 10 Jan 2003 06:42:48 -0500 (EST)
Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0ABk4KX012866;
	Fri, 10 Jan 2003 12:46:04 +0100 (MET)
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <ZGNCBVNY>; Fri, 10 Jan 2003 12:46:00 +0100
Message-ID: <A943FD84BD9ED41193460008C791805003E324B1@ESEALNT419.al.sw.ericsson.se>
From: "Lars-Erik Jonsson (EAB)" <Lars-Erik.Jonsson@epl.ericsson.se>
To: "'Holmes, Matthew, CND Tech Dev, VF UK'"
	 <Matthew.Holmes@gb.vodafone.co.uk>,
        rohc@ietf.org
Subject: RE: [rohc] Question about R-Mode and packet types
Date: Fri, 10 Jan 2003 12:45:55 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Matthew,

You are totally correct, of course you will have to send
"larger" headers if the information to send can not be
conveyed with an R-0-CRC, that is a general compression
principle. The text you refer to could have said "After
these headers have been sent, if the compressor has not
received an ACK to at least one of the previously sent
R-0-CRC, it should not send R-0 headers before it
receives a corresponding ACK."

Cheers,
/L-E


> -----Original Message-----
> From: Holmes, Matthew, CND Tech Dev, VF UK
> [mailto:Matthew.Holmes@gb.vodafone.co.uk]
> Sent: den 10 januari 2003 12:29
> To: rohc@ietf.org
> Subject: [rohc] Question about R-Mode and packet types
> 
> 
> Hi All
> 
> I'm a little confused with the following description in RFC 
> 3095 section 5.5.1.2 where an example of an algorithm to 
> update packets is given:
> 
> Let pRTT be the number of packets that are sent during one 
> round-trip time. In the SO state, when (64 - pRTT) headers 
> have been sent since the last acked reference, the compressor 
> will send m1 consecutive R-0-CRC headers, then send (pRTT - 
> m1) R-0 headers. After these headers have been sent, if the 
> compressor has not received an ACK to at least one of the 
> previously sent R0-CRC, it sends R-0-CRC headers continuously 
> until it receives a corresponding ACK. m1 is an 
> implementation parameter, which can be as large as pRTT.
> 
> I understand it up until the part when it says that if no ACK 
> has been received R-0-CRC packets will be continuously sent. 
> At some point though surely the compressor will have to start 
> sending type 2 packets to included a larger SN. With the last 
> ACKed reference number which the compressor has stored the SN 
> in the R-0-CRC packet will become to small.
> 
> Any help clarifying the above would be much appreciated,
> 
> Thank you
> 
> Matthew Holmes
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
> 
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Sun Jan 12 03:01:05 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06758
	for <rohc-archive@odin.ietf.org>; Sun, 12 Jan 2003 03:01:04 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0C8E7r18916
	for rohc-archive@odin.ietf.org; Sun, 12 Jan 2003 03:14:07 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0C8E7J18913
	for <rohc-web-archive@optimus.ietf.org>; Sun, 12 Jan 2003 03:14:07 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06744
	for <rohc-web-archive@ietf.org>; Sun, 12 Jan 2003 03:00:21 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0C8DfJ18900;
	Sun, 12 Jan 2003 03:13:41 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0C8CFJ18875
	for <rohc@optimus.ietf.org>; Sun, 12 Jan 2003 03:12:15 -0500
Received: from dog.topology.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06703
	for <rohc@ietf.org>; Sun, 12 Jan 2003 02:58:39 -0500 (EST)
Received: (from akenning@localhost)
	by dog.topology.org (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id h0C81rj06370;
	Sun, 12 Jan 2003 18:31:53 +1030
X-Authentication-Warning: dog.topology.org: akenning set sender to ak.rohc@topology.org using -f
Date: Sun, 12 Jan 2003 18:31:53 +1030
From: Alan Kennington <ak.rohc@topology.org>
To: rohc@ietf.org
Message-ID: <20030112183153.A6328@dog.topology.org>
Reply-To: Alan Kennington  <ak.rohc@topology.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.12i
X-PGP-Key: http://www.topology.org/ak/key_ak2.asc
X-PGP-Key-Fingerprint: 8A7B 7A8E 1C02 8298 579F 1860 7D56 121B D363 329E
Subject: [rohc] resource (CID) reclamation
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

How are CIDs reclaimed?

I've looked through RFC 3095 several times, but I can't
find the equivalent of a TCP "FIN" in the protocol.

It seems like if the compressor allocated a CID, then it is
allocated for life.
Is the only way to terminate a context the issuing of an IR packet
to establish a new context?
This, however, seems to create a new context.
Ideally there should be a fourth mode - non-existent mode - which
means that the CID is completely free.
This `non-existent mode' should ideally have a well-defined handshake protocol
for mode transition like the other modes.
But I see nothing like this.

With UDP packets, you never know when the context is really finished.
So I imagine you would time out a context after a long period of inactivity.
And if you run out of CIDs, I imagine you reclaim the most idle open CID.

If there is something in RFC 3095 which I have missed, please let me know.

Cheers,
Alan Kennington.

--------------------------------------------------------------------
    name: Dr. Alan Kennington
 website: http://www.topology.org/
    city: Adelaide, South Australia
  coords: 138.59 E, 34.88 S
timezone: UTC+1030 http://www.topology.org/site/timezone.html
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Sun Jan 12 11:05:56 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11576
	for <rohc-archive@odin.ietf.org>; Sun, 12 Jan 2003 11:05:56 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0CGJ9B11563
	for rohc-archive@odin.ietf.org; Sun, 12 Jan 2003 11:19:09 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0CGJ8J11560
	for <rohc-web-archive@optimus.ietf.org>; Sun, 12 Jan 2003 11:19:08 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11564
	for <rohc-web-archive@ietf.org>; Sun, 12 Jan 2003 11:05:01 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0CGIXJ11541;
	Sun, 12 Jan 2003 11:18:33 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0CGHmJ11518
	for <rohc@optimus.ietf.org>; Sun, 12 Jan 2003 11:17:48 -0500
Received: from gandalf.icr.a-star.edu.sg (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11552
	for <rohc@ietf.org>; Sun, 12 Jan 2003 11:03:57 -0500 (EST)
Received: from gwserver.icr.a-star.edu.sg (gwserver.icr.a-star.edu.sg [137.132.31.253])
	by gandalf.icr.a-star.edu.sg (8.12.2+Sun/8.12.2) with ESMTP id h0CG89Xw027628
	for <rohc@ietf.org>; Mon, 13 Jan 2003 00:08:09 +0800 (SGT)
Received: from localhost.localdomain
	([172.16.2.215])
	by gwserver.icr.a-star.edu.sg; Mon, 13 Jan 2003 00:01:38 +0800
Received: by localhost.localdomain (Postfix, from userid 1000)
	id 266E53290A; Mon, 13 Jan 2003 00:07:01 +0800 (SGT)
Date: Mon, 13 Jan 2003 00:07:01 +0800
From: Sukanta Kumar Hazra <sukanta@icr.a-star.edu.sg>
To: rohc@ietf.org
Subject: Re: [rohc] resource (CID) reclamation
Message-ID: <20030112160701.GA13715@icr.a-star.edu.sg>
Mail-Followup-To: rohc@ietf.org
References: <20030112183153.A6328@dog.topology.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030112183153.A6328@dog.topology.org>
User-Agent: Mutt/1.4i
Organization: Institute for Infocomm Research
Phone: +65 68709338
PGP-KEY: http://www.icr.a-star.edu.sg/~sukanta/skhkey.asc
PGP-ID: 0x8E084AD5
Key-Fingerprint: 9C0D B00C C62A 7059 5314  99FC CE90 478A 8E08 4AD5
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

> With UDP packets, you never know when the context is really finished.
> So I imagine you would time out a context after a long period of inactivity.
> And if you run out of CIDs, I imagine you reclaim the most idle open CID.

Yes, that is the desired approach.

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



From mailnull@www1.ietf.org  Mon Jan 13 18:47:17 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28643
	for <rohc-archive@odin.ietf.org>; Mon, 13 Jan 2003 18:47:17 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0E019C00903
	for rohc-archive@odin.ietf.org; Mon, 13 Jan 2003 19:01:09 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E019J00900
	for <rohc-web-archive@optimus.ietf.org>; Mon, 13 Jan 2003 19:01:09 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28602
	for <rohc-web-archive@ietf.org>; Mon, 13 Jan 2003 18:46:45 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E00qJ00848;
	Mon, 13 Jan 2003 19:00:53 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DNxVJ00753
	for <rohc@optimus.ietf.org>; Mon, 13 Jan 2003 18:59:31 -0500
Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28536
	for <rohc@ietf.org>; Mon, 13 Jan 2003 18:45:07 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <CN3C0P76>; Mon, 13 Jan 2003 23:48:26 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED41805DF64F4@rsys002a.roke.co.uk>
From: "West, Mark (ITN)" <mark.a.west@roke.co.uk>
To: Robert Sparks <rsparks@dynamicsoft.com>,
        "Surtees, Abigail"
	 <abigail.surtees@roke.co.uk>
Cc: rohc@ietf.org, adam@dynamicsoft.com
Subject: RE: [rohc] SigComp interoperability test
Date: Mon, 13 Jan 2003 23:48:25 -0000
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-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>


Calling all potential sigcomp interoperability test victims...

(and with many thanks to Robert, for your comments and suggestions for kicking off testing at SIPit.)

I'm certainly keen to do some SigComp testing -- we've had the RFC for *ages* now! ;-)
However (and this statement is verging on the heretical, but...) I don't really have any interest in SIP.  Worse still, I don't have SigComp integrated with a SIP stack [*gasp*].

Now, it's clear that 'SigComp for SIP' is a pretty major area of testing for a lot of people, and that's cool.  Personally, I also feel that there is a need for a degree of testing to be done purely at the SigComp level.  The vexed question is: will there be a chance to do any of this at SIPit?  (Would we even be allowed through the door?!)

Anyway, this begs a couple of questions that I'll throw open to the floor...
i) Is anyone else planning on attending SIPit with a view to doing SigComp testing (in any form?)
ii) If your answer to (i) is 'yes', then are you prepared to spend more than half a day getting to grips with some dedicated SigComp interoperability issues?

Don't be shy!  Let me know what you think...

TIA,

Mark.



> -----Original Message-----
> From: Robert Sparks [mailto:rsparks@dynamicsoft.com]
> Sent: 20 December 2002 16:45
> To: Surtees, Abigail
> Cc: rohc@ietf.org; adam@dynamicsoft.com
> Subject: Re: [rohc] SigComp interoperability test
> 
> 
> 
> On Wed, 2002-12-18 at 13:04, Surtees, Abigail wrote:
> > Hi,
> > 
> > A quick question about the proposed SigComp testing at 
> SIPit, having had a look at the test description document...
> > 
> > It looks like the plan is to test 'SIP over SigComp' - i.e. 
> with SigComp integrated into a SIP stack.  Obviously we've 
> done a fair amount of UDVM testing (torture tests, etc.) and 
> a small amount of SigComp testing.  So, can we assume that 
> SigComp itself will be sufficiently tested by the SIP 
> exchanges?  (Or that SigComp will be previously/subsequently 
> tested in some (as yet undefined) standalone manner?)  Is 
> anyone prepared to confirm or deny this assumption?!
> 
> One way to get at least a thumbnail answer to that question 
> is to start
> an outline of an interop statement for sigcomp and see how 
> much of that
> statement could be filled out based on tests we're currently 
> describing.
> That effort is also likely to suggest further tests we can 
> document and
> perform.
> 
> > 
> > Also how much time is going to be allocated to testing 
> SigComp at SIPit?  (Our main interest would be in testing 
> SigComp -- we don't really have any interest in taking part 
> in general SIP tests...)
> As much time as there is interest. We have a side area for multiparty
> tests that run continually through the event. We typically have
> coordinated efforts taking a half day each, but if there is a group
> that wants to spend the whole week focusing on one thing, the
> resources are there for them to do so. Realistically, I'd expect
> there to be 1/2 to 1 day on this.
> 
> > 
> > Kind regards,
> > 
> > Abbie
> > 
> > Abbie Surtees
> > Engineer
> > Internet Applications and Mobility
> > Roke Manor Research Ltd
> > Tel:   +44 (0) 1794 833131
> > 
> > 
> > _______________________________________________
> > Rohc mailing list
> > Rohc@ietf.org
> > https://www1.ietf.org/mailman/listinfo/rohc
> 
> 
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
> 
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Tue Jan 14 04:43:42 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20042
	for <rohc-archive@odin.ietf.org>; Tue, 14 Jan 2003 04:43:42 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0E9vjF15120
	for rohc-archive@odin.ietf.org; Tue, 14 Jan 2003 04:57:45 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E9vjJ15117
	for <rohc-web-archive@optimus.ietf.org>; Tue, 14 Jan 2003 04:57:45 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20033
	for <rohc-web-archive@ietf.org>; Tue, 14 Jan 2003 04:43:11 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E9vYJ15109;
	Tue, 14 Jan 2003 04:57:34 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E9tIJ15045
	for <rohc@optimus.ietf.org>; Tue, 14 Jan 2003 04:55:19 -0500
Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19993
	for <rohc@ietf.org>; Tue, 14 Jan 2003 04:40:44 -0500 (EST)
Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0E9hwKW021775;
	Tue, 14 Jan 2003 10:43:59 +0100 (MET)
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <ZGNCX5F9>; Tue, 14 Jan 2003 10:43:58 +0100
Message-ID: <A943FD84BD9ED41193460008C791805003FFC509@ESEALNT419.al.sw.ericsson.se>
From: "Jan Christoffersson (EAB)" <Jan.Christoffersson@epl.ericsson.se>
To: "'West, Mark (ITN)'" <mark.a.west@roke.co.uk>,
        Robert Sparks
	 <rsparks@dynamicsoft.com>,
        "Surtees, Abigail"
	 <abigail.surtees@roke.co.uk>
Cc: rohc@ietf.org, adam@dynamicsoft.com
Subject: RE: [rohc] SigComp interoperability test
Date: Tue, 14 Jan 2003 10:33:35 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi,
Yes, Ericsson will be there with our implementation to do some SigComp testing.
It would be good if we could agree on some high level test cases before the meeting.

Is anyone else planning to participate in the SigComp testing? Nokia? Dynamicsoft?

Regards
Jan

-----Original Message-----
From: West, Mark (ITN) [mailto:mark.a.west@roke.co.uk]
Sent: den 14 januari 2003 00:48
To: Robert Sparks; Surtees, Abigail
Cc: rohc@ietf.org; adam@dynamicsoft.com
Subject: RE: [rohc] SigComp interoperability test



Calling all potential sigcomp interoperability test victims...

(and with many thanks to Robert, for your comments and suggestions for kicking off testing at SIPit.)

I'm certainly keen to do some SigComp testing -- we've had the RFC for *ages* now! ;-)
However (and this statement is verging on the heretical, but...) I don't really have any interest in SIP.  Worse still, I don't have SigComp integrated with a SIP stack [*gasp*].

Now, it's clear that 'SigComp for SIP' is a pretty major area of testing for a lot of people, and that's cool.  Personally, I also feel that there is a need for a degree of testing to be done purely at the SigComp level.  The vexed question is: will there be a chance to do any of this at SIPit?  (Would we even be allowed through the door?!)

Anyway, this begs a couple of questions that I'll throw open to the floor...
i) Is anyone else planning on attending SIPit with a view to doing SigComp testing (in any form?)
ii) If your answer to (i) is 'yes', then are you prepared to spend more than half a day getting to grips with some dedicated SigComp interoperability issues?

Don't be shy!  Let me know what you think...

TIA,

Mark.



> -----Original Message-----
> From: Robert Sparks [mailto:rsparks@dynamicsoft.com]
> Sent: 20 December 2002 16:45
> To: Surtees, Abigail
> Cc: rohc@ietf.org; adam@dynamicsoft.com
> Subject: Re: [rohc] SigComp interoperability test
> 
> 
> 
> On Wed, 2002-12-18 at 13:04, Surtees, Abigail wrote:
> > Hi,
> > 
> > A quick question about the proposed SigComp testing at 
> SIPit, having had a look at the test description document...
> > 
> > It looks like the plan is to test 'SIP over SigComp' - i.e. 
> with SigComp integrated into a SIP stack.  Obviously we've 
> done a fair amount of UDVM testing (torture tests, etc.) and 
> a small amount of SigComp testing.  So, can we assume that 
> SigComp itself will be sufficiently tested by the SIP 
> exchanges?  (Or that SigComp will be previously/subsequently 
> tested in some (as yet undefined) standalone manner?)  Is 
> anyone prepared to confirm or deny this assumption?!
> 
> One way to get at least a thumbnail answer to that question 
> is to start
> an outline of an interop statement for sigcomp and see how 
> much of that
> statement could be filled out based on tests we're currently 
> describing.
> That effort is also likely to suggest further tests we can 
> document and
> perform.
> 
> > 
> > Also how much time is going to be allocated to testing 
> SigComp at SIPit?  (Our main interest would be in testing 
> SigComp -- we don't really have any interest in taking part 
> in general SIP tests...)
> As much time as there is interest. We have a side area for multiparty
> tests that run continually through the event. We typically have
> coordinated efforts taking a half day each, but if there is a group
> that wants to spend the whole week focusing on one thing, the
> resources are there for them to do so. Realistically, I'd expect
> there to be 1/2 to 1 day on this.
> 
> > 
> > Kind regards,
> > 
> > Abbie
> > 
> > Abbie Surtees
> > Engineer
> > Internet Applications and Mobility
> > Roke Manor Research Ltd
> > Tel:   +44 (0) 1794 833131
> > 
> > 
> > _______________________________________________
> > Rohc mailing list
> > Rohc@ietf.org
> > https://www1.ietf.org/mailman/listinfo/rohc
> 
> 
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
> 
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Tue Jan 14 10:42:25 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28337
	for <rohc-archive@odin.ietf.org>; Tue, 14 Jan 2003 10:42:25 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0EFuZQ06162
	for rohc-archive@odin.ietf.org; Tue, 14 Jan 2003 10:56:35 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EFuZJ06159
	for <rohc-web-archive@optimus.ietf.org>; Tue, 14 Jan 2003 10:56:35 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28239
	for <rohc-web-archive@ietf.org>; Tue, 14 Jan 2003 10:41:52 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EFuHJ06132;
	Tue, 14 Jan 2003 10:56:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EFt9J06055
	for <rohc@optimus.ietf.org>; Tue, 14 Jan 2003 10:55:09 -0500
Received: from igate2.vodafone.co.uk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28043
	for <rohc@ietf.org>; Tue, 14 Jan 2003 10:40:26 -0500 (EST)
Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id PAA02934; Tue, 14 Jan 2003 15:43:43 GMT
Received: from putney.vfl.vodafone (putney [10.33.112.118])
	by mailguard2 (4.6.1.123) with ESMTP id 
	for <rohc@ietf.org>; Tue, 14 Jan 2003 15:40:22 GMT
Received: from ukwmxc01.vf-uk.internal.vodafone.com (UKWMXC01.vfl.vodafone [10.33.126.160]) by putney.vfl.vodafone with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id YL9ANMGG; Tue, 14 Jan 2003 15:43:13 -0000
Received: from ukwmxc04.vf-uk.internal.vodafone.com ([10.33.126.173]) by ukwmxc01.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.4453);
	 Tue, 14 Jan 2003 15:42:25 +0000
Received: from ukwmxm01.vf-uk.internal.vodafone.com ([10.33.126.162]) by ukwmxc04.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.4453);
	 Tue, 14 Jan 2003 15:42:25 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
Date: Tue, 14 Jan 2003 15:42:25 -0000
Message-ID: <6FC554FA1F33BE4C9AC844FC3B3B71280D1471@UKWMXM01>
Thread-Topic: Channel Parameters
Thread-Index: AcK746Fbc35DQCeWEdebOwBQBFRDqA==
From: "Holmes, Matthew, CND Tech Dev, VF UK" <Matthew.Holmes@gb.vodafone.co.uk>
To: <rohc@ietf.org>
X-OriginalArrivalTime: 14 Jan 2003 15:42:25.0847 (UTC) FILETIME=[897D8470:01C2BBE3]
MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122)
Content-Type: text/plain;	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0EFt9J06056
Subject: [rohc] Channel Parameters
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Hi All

If no feedback path is available then U-Mode would be used. Can some one explain what happens with the channel parameters in this case? How would something like the PROFILES parameter be sent to the compressor? Although feedback is not required for U-Mode is it the case that a two-way link is mandatory for the link establishment?

Any help would be appreciated,

Thank you

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



From mailnull@www1.ietf.org  Wed Jan 15 08:01:37 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24687
	for <rohc-archive@odin.ietf.org>; Wed, 15 Jan 2003 08:01:36 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0FDGEp08284
	for rohc-archive@odin.ietf.org; Wed, 15 Jan 2003 08:16:14 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FDGDJ08281
	for <rohc-web-archive@optimus.ietf.org>; Wed, 15 Jan 2003 08:16:13 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24612
	for <rohc-web-archive@ietf.org>; Wed, 15 Jan 2003 08:01:05 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FDFdJ08170;
	Wed, 15 Jan 2003 08:15:40 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FDDHJ08016
	for <rohc@optimus.ietf.org>; Wed, 15 Jan 2003 08:13:17 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24325;
	Wed, 15 Jan 2003 07:58:09 -0500 (EST)
Message-Id: <200301151258.HAA24325@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: rohc@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 15 Jan 2003 07:58:08 -0500
Subject: [rohc] I-D ACTION:draft-price-rohc-sigcomp-torture-tests-01.txt
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: SigComp Torture Tests
	Author(s)	: R. Price, A. Surtees
	Filename	: draft-price-rohc-sigcomp-torture-tests-01.txt
	Pages		: 11
	Date		: 2003-1-14
	
This document provides a set of 'torture tests' for implementers of 
the SigComp protocol.  The torture tests check each of the SigComp 
Universal Decompressor Virtual Machine instructions in turn, focusing 
in particular on the boundary and error cases that are not generally 
encountered when running well-behaved compression algorithms.  Tests 
are also provided for other SigComp entities such as the dispatcher 
and the state handler.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-price-rohc-sigcomp-torture-tests-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-price-rohc-sigcomp-torture-tests-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-price-rohc-sigcomp-torture-tests-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-1-14150954.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-price-rohc-sigcomp-torture-tests-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-price-rohc-sigcomp-torture-tests-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-1-14150954.I-D@ietf.org>

--OtherAccess--

--NextPart--


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



From mailnull@www1.ietf.org  Wed Jan 15 10:36:40 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00278
	for <rohc-archive@odin.ietf.org>; Wed, 15 Jan 2003 10:36:39 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0FFpLr19413
	for rohc-archive@odin.ietf.org; Wed, 15 Jan 2003 10:51:21 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FFpKJ19410
	for <rohc-web-archive@optimus.ietf.org>; Wed, 15 Jan 2003 10:51:20 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00231
	for <rohc-web-archive@ietf.org>; Wed, 15 Jan 2003 10:36:08 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FFpAJ19351;
	Wed, 15 Jan 2003 10:51:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FFo5J19268
	for <rohc@optimus.ietf.org>; Wed, 15 Jan 2003 10:50:05 -0500
Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00170;
	Wed, 15 Jan 2003 10:34:52 -0500 (EST)
Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0FFcCKV029914;
	Wed, 15 Jan 2003 16:38:12 +0100 (MET)
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <ZGNDD7GV>; Wed, 15 Jan 2003 16:38:12 +0100
Message-ID: <A943FD84BD9ED41193460008C791805003E324CE@ESEALNT419.al.sw.ericsson.se>
From: "Lars-Erik Jonsson (EAB)" <Lars-Erik.Jonsson@epl.ericsson.se>
To: "'rohc@ietf.org'" <rohc@ietf.org>
Cc: "'sigtran@ietf.org'" <sigtran@ietf.org>,
        "'tsvwg@ietf.org'"
	 <tsvwg@ietf.org>,
        "Allison Mankin (E-mail)" <mankin@psg.com>
Date: Wed, 15 Jan 2003 16:38:03 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [rohc] Removing SCTP header compression from the ROHC charter
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

ROHCers (cc sigtran & tsvwg),

The current ROHC WG charter has SCTP header compression listed as
one of our work items.  When this item was added, activity within
the ROHC WG was high, and the addition was made as a prediction of
future expectations rather than an outcome of well justified
immediate requirements.

Trying to fulfill this work item during the last year, we have
repeatedly asked for contributions to SCTP header compression, but
we have not received a single response.

Given that this work item was originally added without immediate
market pull, and considering the lack of current interest in doing
the work (or even having it done at all), we intend to remove SCTP
header compression from the ROHC WG charter.  To keep it in the
charter, justifications for developing SCTP header compression now
would have to be presented, as well as industry support and
commitments for doing the actual work.

Barring further input, we will send a request to the ADs by Jan 24,
so please reply before this date if you believe SCTP header
compression should be on the agenda now.

/Lars-Erik & Carsten
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Wed Jan 15 11:19:40 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01801
	for <rohc-archive@odin.ietf.org>; Wed, 15 Jan 2003 11:19:40 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0FGYKr22654
	for rohc-archive@odin.ietf.org; Wed, 15 Jan 2003 11:34:20 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGYKJ22651
	for <rohc-web-archive@optimus.ietf.org>; Wed, 15 Jan 2003 11:34:20 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01780
	for <rohc-web-archive@ietf.org>; Wed, 15 Jan 2003 11:19:09 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGY9J22624;
	Wed, 15 Jan 2003 11:34:09 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGXCJ22501
	for <rohc@optimus.ietf.org>; Wed, 15 Jan 2003 11:33:12 -0500
Received: from nmh.informatik.uni-bremen.de (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01734
	for <rohc@ietf.org>; Wed, 15 Jan 2003 11:18:00 -0500 (EST)
Received: from marie.local..informatik.uni-bremen.de (IDENT:MGlWFmp0zQLUwfRPokjeI4hvPnCe1G8m@roman.informatik.uni-bremen.de [134.102.218.120])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id h0FGLHd25178;
	Wed, 15 Jan 2003 17:21:18 +0100 (MET)
X-Mailer: emacs 21.3.50.2 (via feedmail 8 I)
To: ROHC WG <rohc@ietf.org>
From: cabo@tzi.org (Carsten Bormann)
Date: Wed, 15 Jan 2003 17:20:59 +0100
Message-ID: <m2lm1mtmdw.fsf@marie.local.>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [rohc] WG last-call for ROHC MIB and related documents
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

ROHCers,

In Atlanta, we said we were going to have another re-spin of the ROHC
MIB to include LLA.  This has now been available for nearly a month,
and we believe the document has received enough review to issue the WG
last-call.  Together with this goes the terminology and examples
document as additional explanatory material that at some point is
expected to become part of the ROHC draft standard.

Therefore, we are now issuing a WG last-call for the following two
documents:

  draft-ietf-rohc-mib-rtp-05.txt
      (for publication as Proposed Standard)

  draft-ietf-rohc-terminology-and-examples-01.txt
      (for publication as Informational)

This is a regular two-week WG last-call.

Please direct WG last-call comments to the ROHC mailing list
rohc@ietf.org before Wed, 2003-01-29, 18:00 UTC.

Gruesse, Carsten

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



From mailnull@www1.ietf.org  Thu Jan 16 16:08:25 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23995
	for <rohc-archive@odin.ietf.org>; Thu, 16 Jan 2003 16:08:25 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0GLNfW24364
	for rohc-archive@odin.ietf.org; Thu, 16 Jan 2003 16:23:41 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GLNfJ24361
	for <rohc-web-archive@optimus.ietf.org>; Thu, 16 Jan 2003 16:23:41 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23978
	for <rohc-web-archive@ietf.org>; Thu, 16 Jan 2003 16:07:53 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GLNHJ24313;
	Thu, 16 Jan 2003 16:23:20 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GLMfJ24275
	for <rohc@optimus.ietf.org>; Thu, 16 Jan 2003 16:22:41 -0500
Received: from marjan.fesb.hr (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23964
	for <rohc@ietf.org>; Thu, 16 Jan 2003 16:06:53 -0500 (EST)
Received: (from root@localhost)
	by marjan.fesb.hr (8.12.3/8.12.1/Debian -5) id h0GLAEtU018448;
	Thu, 16 Jan 2003 22:10:14 +0100
Received: from fesb.hr (demorgan.bit.fesb.hr [161.53.169.245])
	(authenticated bits=0)
	by marjan.fesb.hr (8.12.3/8.12.1/Debian -5) with ESMTP id h0GLAArM018435;
	Thu, 16 Jan 2003 22:10:12 +0100
Message-ID: <3E272072.8060907@fesb.hr>
Date: Thu, 16 Jan 2003 22:13:22 +0100
From: Julije Ozegovic <julije@fesb.hr>
Organization: FESB Split
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en, hr
MIME-Version: 1.0
To: rohc@ietf.org
CC: "Lars-Erik Jonsson (EAB)" <Lars-Erik.Jonsson@epl.ericsson.se>
Subject: Re: [rohc] Removing SCTP header compression from the ROHC charter
References: <A943FD84BD9ED41193460008C791805003E324CE@ESEALNT419.al.sw.ericsson.se>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS perl-11
Content-Transfer-Encoding: 7bit
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

ROHCers,

I would like to inform you that our EPIC-Lite implementation 
(postgraduate students project at University of Split, FESB 
Split) successfully compiles SCTP profiles based on
draft-west-sctp-epic-00.txt (already expired).

However, I must admit that no compression - decompression 
testing has been done because no SCTP flow was available. We 
hope to include SCTP tests as soon as possible.

EPIC-Lite implementation is based on
draft-ietf-rohc-epic-lite-01.txt (already expired).
The duration of project was one year (school year 2001/2002).

The interoperability testing with Roke Manor reference 
implementation was successful.

Currently, the code is being prepared for public release, GNU 
licence, as-is, together with all tests finished on Linux and 
Windows machines.

We intend to inform ROHC community about the availability of 
code at the moment of release.

Best regards,
Julije Ozegovic



Lars-Erik Jonsson (EAB) wrote:
> ROHCers (cc sigtran & tsvwg),
> 
> The current ROHC WG charter has SCTP header compression listed as
> one of our work items.  When this item was added, activity within
> the ROHC WG was high, and the addition was made as a prediction of
> future expectations rather than an outcome of well justified
> immediate requirements.
> 
> Trying to fulfill this work item during the last year, we have
> repeatedly asked for contributions to SCTP header compression, but
> we have not received a single response.
> 
> Given that this work item was originally added without immediate
> market pull, and considering the lack of current interest in doing
> the work (or even having it done at all), we intend to remove SCTP
> header compression from the ROHC WG charter.  To keep it in the
> charter, justifications for developing SCTP header compression now
> would have to be presented, as well as industry support and
> commitments for doing the actual work.
> 
> Barring further input, we will send a request to the ADs by Jan 24,
> so please reply before this date if you believe SCTP header
> compression should be on the agenda now.
> 
> /Lars-Erik & Carsten
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
> 
> 


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



From mailnull@www1.ietf.org  Fri Jan 17 02:43:07 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14938
	for <rohc-archive@odin.ietf.org>; Fri, 17 Jan 2003 02:43:07 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0H7waY07530
	for rohc-archive@odin.ietf.org; Fri, 17 Jan 2003 02:58:36 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H7wZJ07527
	for <rohc-web-archive@optimus.ietf.org>; Fri, 17 Jan 2003 02:58:35 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14932
	for <rohc-web-archive@ietf.org>; Fri, 17 Jan 2003 02:42:35 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H7wPJ07518;
	Fri, 17 Jan 2003 02:58:25 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H7voJ07483
	for <rohc@optimus.ietf.org>; Fri, 17 Jan 2003 02:57:50 -0500
Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14921
	for <rohc@ietf.org>; Fri, 17 Jan 2003 02:41:49 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <CN3C040X>; Fri, 17 Jan 2003 07:45:11 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED4180663673A@rsys002a.roke.co.uk>
From: "West, Mark (ITN)" <mark.a.west@roke.co.uk>
To: "'rohc@ietf.org'" <rohc@ietf.org>
Subject: RE: [rohc] Removing SCTP header compression from the ROHC charter
Date: Fri, 17 Jan 2003 07:45:09 -0000
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-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>


Hi all,

Just a couple of comments in passing...

My view is that SCTP compression is going to be done, sooner or later.  And rohc feels like a logical place to do it (but it would be nice if an SCTP activist could confirm, for example, that SCTP has a place in the mobile environment)...  In practice, I assume that the main point of the request is to solicit assertions that SCTP compression is necessary?  And I guess I'll have to leave that to others..!

Technically, it's not immediately clear to me what work *needs* to be done on SCTP header compression, at least in the short term.  After all, one of the questions has to be: can we re-use the approach being developed for TCP?  The obvious next step, I suppose, would be an equivalent of the TCP behaviour (sorry, 'behavior') draft?

Cheers,

Mark.


> -----Original Message-----
> From: Lars-Erik Jonsson (EAB) 
> [mailto:Lars-Erik.Jonsson@epl.ericsson.se]
> Sent: 15 January 2003 15:38
> To: 'rohc@ietf.org'
> Cc: 'sigtran@ietf.org'; 'tsvwg@ietf.org'; Allison Mankin (E-mail)
> Subject: [rohc] Removing SCTP header compression from the ROHC charter
> 
> 
> ROHCers (cc sigtran & tsvwg),
> 
> The current ROHC WG charter has SCTP header compression listed as
> one of our work items.  When this item was added, activity within
> the ROHC WG was high, and the addition was made as a prediction of
> future expectations rather than an outcome of well justified
> immediate requirements.
> 
> Trying to fulfill this work item during the last year, we have
> repeatedly asked for contributions to SCTP header compression, but
> we have not received a single response.
> 
> Given that this work item was originally added without immediate
> market pull, and considering the lack of current interest in doing
> the work (or even having it done at all), we intend to remove SCTP
> header compression from the ROHC WG charter.  To keep it in the
> charter, justifications for developing SCTP header compression now
> would have to be presented, as well as industry support and
> commitments for doing the actual work.
> 
> Barring further input, we will send a request to the ADs by Jan 24,
> so please reply before this date if you believe SCTP header
> compression should be on the agenda now.
> 
> /Lars-Erik & Carsten
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
> 
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Fri Jan 17 04:53:18 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16816
	for <rohc-archive@odin.ietf.org>; Fri, 17 Jan 2003 04:53:18 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0HA8oE16974
	for rohc-archive@odin.ietf.org; Fri, 17 Jan 2003 05:08:50 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HA8oJ16971
	for <rohc-web-archive@optimus.ietf.org>; Fri, 17 Jan 2003 05:08:50 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16811
	for <rohc-web-archive@ietf.org>; Fri, 17 Jan 2003 04:52:47 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HA8NJ16949;
	Fri, 17 Jan 2003 05:08:23 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HA7BJ16537
	for <rohc@optimus.ietf.org>; Fri, 17 Jan 2003 05:07:11 -0500
Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16791
	for <rohc@ietf.org>; Fri, 17 Jan 2003 04:51:07 -0500 (EST)
Received: from venus.office (venus.office [10.1.1.11])
	by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h0H9sTR61947;
	Fri, 17 Jan 2003 10:54:30 +0100 (CET)
	(envelope-from quittek@ccrle.nec.de)
Received: from [10.1.1.128] (n-quittek.office [10.1.1.128])
	by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id 650E484C57; Fri, 17 Jan 2003 12:02:31 +0100 (CET)
Date: Fri, 17 Jan 2003 10:55:32 +0100
From: Juergen Quittek <quittek@ccrle.nec.de>
To: Carsten Bormann <cabo@tzi.org>, ROHC WG <rohc@ietf.org>
Subject: Re: [rohc] WG last-call for ROHC MIB and related documents
Message-ID: <4737712.1042800932@[10.1.1.128]>
In-Reply-To: <m2lm1mtmdw.fsf@marie.local.>
References:  <m2lm1mtmdw.fsf@marie.local.>
X-Mailer: Mulberry/2.1.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

ROHCers,

In order to facilitate your review of draft-ietf-rohc-mib-rtp-05.txt,
I point out the changes between version -04 and -05 below.

The draft contains three MIB modules: ROHC-MIB, ROHC-UNCOMPRESSED-MIB,
and ROHC-RTP-MIB. The ROHC-MIB module defines properties of ROHC instances,
ROHC channels, ROHC profiles, and ROHC compressor and decompressor contexts.
All managed objects in this module are assumed to be shared by all profiles.

The ROHC-UNCOMPRESSED-MIB module extends the ROHC-MIB by managed objects
that are specific to the ROHC uncompressed profile 0x0000 defined in RFC 3095.
The ROHC-RTP-MIB module so far extended the ROHC-MIB by managed objects that
are specific to the three other profiles defined in RFC 3095 (ROHC RTP profile
0x0001, ROHC UDP profile 0x0002, and ROHC ESP profile 0x0003.

Since version -05 also the ROHC LLA profile 0x0005 (defined in RFC 3242) is
supported by the ROHC-RTP-MIB module. For this purpose, the following managed
objects were added to entries of the rohcRtpContextTable:

rohcRtpContextAlwaysPad:
        "Boolean, only applicable to compressor contexts using the
         LLA profile.  If its value is true, the compressor must
         pad every RHP packet with a minimum of one octet ROHC
         padding."
    REFERENCE
        "RFC 3242, Section 5.1.1"
    DEFVAL { false }

rohcRtpContextLargePktsAllowed:
        "Boolean, only applicable to compressor contexts using the
         LLA profile.  It specifies how to handle packets that do
         not fit any of the preferred packet sizes specified.  If
         its value is true, the compressor must deliver the larger
         packet as-is and must not use segmentation.  If it is set
         to false, the ROHC segmentation scheme must be used to
         split the packet into two or more segments, and each
         segment must further be padded to fit one of the preferred
         packet sizes."
    REFERENCE
        "RFC 3242, Section 5.1.1"
    DEFVAL { true }

rohcRtpContextVerifyPeriod OBJECT-TYPE
        "This object is only applicable to compressor contexts
         using the LLA profile.  It specifies the minimum frequency
         with which a packet validating the context must be sent.
         This tells the compressor that a packet containing a CRC
         field must be sent at least once every N packets, where N
         is the value of the object. A value of 0 indicates that
         periodical verifications are disabled."
    REFERENCE
        "RFC 3242, Section 5.1.1"
    DEFVAL { 0 }

rohcRtpContextNHPs OBJECT-TYPE
        "This object is only applicable to contexts using the
         LLA profile.  It contains the number of all no-header
         packets (NHP) sent or received in this context, respectively."
    REFERENCE
        "RFC 3242, Section 4.1.1."

rohcRtpContextCSPs OBJECT-TYPE
        "This object is only applicable to contexts using the
         LLA profile.  It contains the number of all context
         synchronization packets (CSP) sent or received in this
         context, respectively."
    REFERENCE
        "RFC 3242, Section 4.1.2."
rohcRtpContextCCPs OBJECT-TYPE
        "This object is only applicable to contexts using the
         LLA profile.  It contains the number of all context check
         packets (CCP) sent or received in this context, respectively."
    REFERENCE
        "RFC 3242, Section 4.1.3."

rohcRtpContextPktsLostPhysical OBJECT-TYPE
        "This object is only applicable to decompressor contexts
         using the LLA profile.  It contains the number of physical
         packet losses on the link between compressor and
         decompressor, that have been indicated to the decompressor."
    REFERENCE
        "RFC 3242, Section 5.1.2."

rohcRtpContextPktsLostPreLink OBJECT-TYPE
        "This object is only applicable to decompressor contexts
         using the LLA profile.  It contains the number of pre-link
         packet losses on the link between compressor and
         decompressor, that have been indicated to the decompressor."
    REFERENCE
        "RFC 3242, Section 5.1.2."

The rohcRtpPacketSizeTable was extended such that in addition to "allowed"
 and "used" packet sizes (RFC 3095), it may also contain "preferred" packets
sizes (RFC3242). If a packet sizes in the table is allowed, preferred,
and/or used is indicated by three boolean managed objects called
rohcRtpPacketSizeAllowed, rohcRtpPacketSizePreferred, and
rohcRtpPacketSizeUsed. Additionally, the new managed object
rohcRtpPacketSizeRestrictedType indicates restrictions of preferred sizes:

rohcRtpPacketSizeRestrictedType
    SYNTAX      INTEGER {
                    nhpOnly(1),
                    rhpOnly(2),
                    noRestrictions(3)
                }
    DESCRIPTION
        "This object is only applicable to preferred packet
         sizes of compressor contexts using the LLA profile.
         When retrieved, it will indicate whether the packet
         size is preferred for NHP only, for RHP only, or
         for both of them."
    REFERENCE
         "RFC 3242, Section 5.1.1"

Have fun with the review!

    Juergen

-- Carsten Bormann wrote on 15 January 2003 17:20 +0100:

> ROHCers,
>
> In Atlanta, we said we were going to have another re-spin of the ROHC
> MIB to include LLA.  This has now been available for nearly a month,
> and we believe the document has received enough review to issue the WG
> last-call.  Together with this goes the terminology and examples
> document as additional explanatory material that at some point is
> expected to become part of the ROHC draft standard.
>
> Therefore, we are now issuing a WG last-call for the following two
> documents:
>
>   draft-ietf-rohc-mib-rtp-05.txt
>       (for publication as Proposed Standard)
>
>   draft-ietf-rohc-terminology-and-examples-01.txt
>       (for publication as Informational)
>
> This is a regular two-week WG last-call.
>
> Please direct WG last-call comments to the ROHC mailing list
> rohc@ietf.org before Wed, 2003-01-29, 18:00 UTC.
>
> Gruesse, Carsten
>
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc


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



From mailnull@www1.ietf.org  Fri Jan 17 06:07:52 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17992
	for <rohc-archive@odin.ietf.org>; Fri, 17 Jan 2003 06:07:52 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0HBNQg21614
	for rohc-archive@odin.ietf.org; Fri, 17 Jan 2003 06:23:26 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HBNQJ21611
	for <rohc-web-archive@optimus.ietf.org>; Fri, 17 Jan 2003 06:23:26 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17976
	for <rohc-web-archive@ietf.org>; Fri, 17 Jan 2003 06:07:21 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HBNFJ21603;
	Fri, 17 Jan 2003 06:23:15 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HBMtJ21578
	for <rohc@optimus.ietf.org>; Fri, 17 Jan 2003 06:22:55 -0500
Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17967
	for <rohc@ietf.org>; Fri, 17 Jan 2003 06:06:49 -0500 (EST)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0HBABAv003250
	for <rohc@ietf.org>; Fri, 17 Jan 2003 12:10:11 +0100 (MET)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <ZGNB41XT>; Fri, 17 Jan 2003 12:10:11 +0100
Message-ID: <F005CD411D18D3119C8F00508B0874800A14465D@ehubunt100.eth.ericsson.se>
From: "Lajos Zaccomer (ETH)" <Lajos.Zaccomer@eth.ericsson.se>
To: rohc@ietf.org
Date: Fri, 17 Jan 2003 12:07:57 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-2"
Subject: [rohc] Torture test - 2.4. SHA-1
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi,

The test of subject starts with 36480 available cpb (if defaut cycles_per_bit = 16 is used) in our implementation. I think it's all right, because the sigcomp message is 160 bytes long, thus available cpb = (1000 + 8 * 160) * 16 = 36480 < 66327 that the execution of the whole test costs. The result is decompression failure when trying to execute the 3rd SHA-1.
I suggest that this should also be corrected in the next draft that it could be executed with default cpb.

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



From mailnull@www1.ietf.org  Fri Jan 17 09:05:47 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22659
	for <rohc-archive@odin.ietf.org>; Fri, 17 Jan 2003 09:05:46 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0HELNM01968
	for rohc-archive@odin.ietf.org; Fri, 17 Jan 2003 09:21:23 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HELNJ01965
	for <rohc-web-archive@optimus.ietf.org>; Fri, 17 Jan 2003 09:21:23 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22649
	for <rohc-web-archive@ietf.org>; Fri, 17 Jan 2003 09:05:15 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HELDJ01952;
	Fri, 17 Jan 2003 09:21:13 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HEK3J01847
	for <rohc@optimus.ietf.org>; Fri, 17 Jan 2003 09:20:03 -0500
Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22605
	for <rohc@ietf.org>; Fri, 17 Jan 2003 09:03:54 -0500 (EST)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0HE78Aw003820;
	Fri, 17 Jan 2003 15:07:16 +0100 (MET)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <ZGNBVX78>; Fri, 17 Jan 2003 15:07:07 +0100
Message-ID: <F005CD411D18D3119C8F00508B0874800A14465E@ehubunt100.eth.ericsson.se>
From: "Lajos Zaccomer (ETH)" <Lajos.Zaccomer@eth.ericsson.se>
To: "'Price, Richard'" <richard.price@roke.co.uk>, rohc@ietf.org
Subject: RE: [rohc] COPY_LITERAL and COPY_OFFSET torture test
Date: Fri, 17 Jan 2003 15:05:00 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi,

The updated draft still does not inform the users to set at least 32K UDVM memory. Either this notification should be inserted or the test should be modified that it can be run with UMS=2048. I vote for the latter one.
If the parameters may change test by test, there should be a short configuration instruction at the beginning of each test.

BR/Zacco

-----Original Message-----
From: Price, Richard [mailto:richard.price@roke.co.uk]
Sent: Tuesday, December 10, 2002 12:04 PM
To: 'Mural Kumar'; rohc@ietf.org
Subject: RE: [rohc] COPY_LITERAL and COPY_OFFSET torture test


Hi Mural,

You're right that some of the torture tests require more than
4K of UDVM memory. For this particular test a minimum of 32K is
required, so it's correct for the UDVM to give an "out of memory"
error when running with only 4K.

Regards,

Richard

-----Original Message-----
From: Mural Kumar [mailto:murali_gvl@yahoo.com]
Sent: Monday, December 09, 2002 2:55 AM
To: rohc@ietf.org
Subject: [rohc] COPY_LITERAL and COPY_OFFSET torture test


Hi,
  I'm having problems with my UDVM on sigcomp torture test for COPY_LITERAL and COPY_OFFSET. Problem arises while executing LOAD ($offset, 1) instruction. The contents of udvm at address "offset" and "offset+1" are 0x40 and 0x40 before executing the LOAD instruction. So, LOAD fails claiming "address out of udvm memory" (I allocated 4k to UDVM). 
Does sigcomp tests expects 64k memory for UDVM? Did anyone had any problems executing this particular torture test?
thanks in advance,
murali.




Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Fri Jan 17 09:28:45 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23076
	for <rohc-archive@odin.ietf.org>; Fri, 17 Jan 2003 09:28:45 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0HEiMu03488
	for rohc-archive@odin.ietf.org; Fri, 17 Jan 2003 09:44:22 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HEiMJ03485
	for <rohc-web-archive@optimus.ietf.org>; Fri, 17 Jan 2003 09:44:22 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23069
	for <rohc-web-archive@ietf.org>; Fri, 17 Jan 2003 09:28:14 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HEi9J03475;
	Fri, 17 Jan 2003 09:44:09 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HEhVJ03452
	for <rohc@optimus.ietf.org>; Fri, 17 Jan 2003 09:43:31 -0500
Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23049
	for <rohc@ietf.org>; Fri, 17 Jan 2003 09:27:22 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <CN3C0V64>; Fri, 17 Jan 2003 14:30:43 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F190@rsys002a.roke.co.uk>
From: "Price, Richard" <richard.price@roke.co.uk>
To: "'Lajos Zaccomer (ETH)'" <Lajos.Zaccomer@eth.ericsson.se>, rohc@ietf.org
Subject: RE: [rohc] COPY_LITERAL and COPY_OFFSET torture test
Date: Fri, 17 Jan 2003 14:30:42 -0000
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-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi,

Thanks for reminding me of this! I thought I'd updated all of the
tests to run in 2K but it looks like I missed one. Let me know
if there are any others so that they can be fixed in the next
version of the draft.

Regards,

Richard

> -----Original Message-----
> From: Lajos Zaccomer (ETH) [mailto:Lajos.Zaccomer@eth.ericsson.se]
> Sent: Friday, January 17, 2003 2:05 PM
> To: Price, Richard; rohc@ietf.org
> Subject: RE: [rohc] COPY_LITERAL and COPY_OFFSET torture test
> 
> 
> Hi,
> 
> The updated draft still does not inform the users to set at 
> least 32K UDVM memory. Either this notification should be 
> inserted or the test should be modified that it can be run 
> with UMS=2048. I vote for the latter one.
> If the parameters may change test by test, there should be a 
> short configuration instruction at the beginning of each test.
> 
> BR/Zacco
> 
> -----Original Message-----
> From: Price, Richard [mailto:richard.price@roke.co.uk]
> Sent: Tuesday, December 10, 2002 12:04 PM
> To: 'Mural Kumar'; rohc@ietf.org
> Subject: RE: [rohc] COPY_LITERAL and COPY_OFFSET torture test
> 
> 
> Hi Mural,
> 
> You're right that some of the torture tests require more than
> 4K of UDVM memory. For this particular test a minimum of 32K is
> required, so it's correct for the UDVM to give an "out of memory"
> error when running with only 4K.
> 
> Regards,
> 
> Richard
> 
> -----Original Message-----
> From: Mural Kumar [mailto:murali_gvl@yahoo.com]
> Sent: Monday, December 09, 2002 2:55 AM
> To: rohc@ietf.org
> Subject: [rohc] COPY_LITERAL and COPY_OFFSET torture test
> 
> 
> Hi,
>   I'm having problems with my UDVM on sigcomp torture test 
> for COPY_LITERAL and COPY_OFFSET. Problem arises while 
> executing LOAD ($offset, 1) instruction. The contents of udvm 
> at address "offset" and "offset+1" are 0x40 and 0x40 before 
> executing the LOAD instruction. So, LOAD fails claiming 
> "address out of udvm memory" (I allocated 4k to UDVM). 
> Does sigcomp tests expects 64k memory for UDVM? Did anyone 
> had any problems executing this particular torture test?
> thanks in advance,
> murali.
> 
> 
> 
> 
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
> 
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Fri Jan 17 09:40:44 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23644
	for <rohc-archive@odin.ietf.org>; Fri, 17 Jan 2003 09:40:44 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0HEuL204356
	for rohc-archive@odin.ietf.org; Fri, 17 Jan 2003 09:56:21 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HEuLJ04353
	for <rohc-web-archive@optimus.ietf.org>; Fri, 17 Jan 2003 09:56:21 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23635
	for <rohc-web-archive@ietf.org>; Fri, 17 Jan 2003 09:40:12 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HEu9J04344;
	Fri, 17 Jan 2003 09:56:09 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HEtkJ04180
	for <rohc@optimus.ietf.org>; Fri, 17 Jan 2003 09:55:46 -0500
Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23545
	for <rohc@ietf.org>; Fri, 17 Jan 2003 09:39:36 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <CN3C0V76>; Fri, 17 Jan 2003 14:42:58 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F191@rsys002a.roke.co.uk>
From: "Price, Richard" <richard.price@roke.co.uk>
To: "'Lajos Zaccomer (ETH)'" <Lajos.Zaccomer@eth.ericsson.se>, rohc@ietf.org
Subject: RE: [rohc] Torture test - 2.4. SHA-1
Date: Fri, 17 Jan 2003 14:42:58 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-2"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi,

For this particular test we deliberately use more than the
default number of UDVM cycles. It's important to test the SHA-1
instruction with the largest possible input size of 65535 bytes
(e.g. to make sure that it doesn't cause any buffers to overflow),
which means that the total cost of the test must be at least 2^16
UDVM cycles.

Would it be useful to have a note in the draft pointing out that
since the test needs a total of 66327 UDVM cycles, it must be
executed with a cpb of at least 32?

Regards,

Richard

> -----Original Message-----
> From: Lajos Zaccomer (ETH) [mailto:Lajos.Zaccomer@eth.ericsson.se]
> Sent: Friday, January 17, 2003 11:08 AM
> To: rohc@ietf.org
> Subject: [rohc] Torture test - 2.4. SHA-1
>
>
> Hi,
>
> The test of subject starts with 36480 available cpb (if
> defaut cycles_per_bit = 16 is used) in our implementation. I
> think it's all right, because the sigcomp message is 160
> bytes long, thus available cpb = (1000 + 8 * 160) * 16 =
> 36480 < 66327 that the execution of the whole test costs. The
> result is decompression failure when trying to execute the 3rd SHA-1.
> I suggest that this should also be corrected in the next
> draft that it could be executed with default cpb.
>
> BR/Zacco
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
> 
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Fri Jan 17 09:45:35 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23892
	for <rohc-archive@odin.ietf.org>; Fri, 17 Jan 2003 09:45:35 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0HF1Da04709
	for rohc-archive@odin.ietf.org; Fri, 17 Jan 2003 10:01:13 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HF1DJ04706
	for <rohc-web-archive@optimus.ietf.org>; Fri, 17 Jan 2003 10:01:13 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23874
	for <rohc-web-archive@ietf.org>; Fri, 17 Jan 2003 09:45:04 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HF13J04697;
	Fri, 17 Jan 2003 10:01:03 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HF05J04606
	for <rohc@optimus.ietf.org>; Fri, 17 Jan 2003 10:00:05 -0500
Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23817
	for <rohc@ietf.org>; Fri, 17 Jan 2003 09:43:56 -0500 (EST)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0HElIKW006388;
	Fri, 17 Jan 2003 15:47:18 +0100 (MET)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <ZGNBWCL0>; Fri, 17 Jan 2003 15:47:17 +0100
Message-ID: <F005CD411D18D3119C8F00508B0874800A144661@ehubunt100.eth.ericsson.se>
From: "Lajos Zaccomer (ETH)" <Lajos.Zaccomer@eth.ericsson.se>
To: "'Price, Richard'" <richard.price@roke.co.uk>, rohc@ietf.org
Subject: RE: [rohc] Torture test - 2.4. SHA-1
Date: Fri, 17 Jan 2003 15:44:01 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-2"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi,

I think it would be useful to describe a default test configuration at the beginning, and any alteration from that should be indicated before each test.

BR/Zacco

-----Original Message-----
From: Price, Richard [mailto:richard.price@roke.co.uk]
Sent: Friday, January 17, 2003 3:43 PM
To: 'Lajos Zaccomer (ETH)'; rohc@ietf.org
Subject: RE: [rohc] Torture test - 2.4. SHA-1


Hi,

For this particular test we deliberately use more than the
default number of UDVM cycles. It's important to test the SHA-1
instruction with the largest possible input size of 65535 bytes
(e.g. to make sure that it doesn't cause any buffers to overflow),
which means that the total cost of the test must be at least 2^16
UDVM cycles.

Would it be useful to have a note in the draft pointing out that
since the test needs a total of 66327 UDVM cycles, it must be
executed with a cpb of at least 32?

Regards,

Richard

> -----Original Message-----
> From: Lajos Zaccomer (ETH) [mailto:Lajos.Zaccomer@eth.ericsson.se]
> Sent: Friday, January 17, 2003 11:08 AM
> To: rohc@ietf.org
> Subject: [rohc] Torture test - 2.4. SHA-1
>
>
> Hi,
>
> The test of subject starts with 36480 available cpb (if
> defaut cycles_per_bit = 16 is used) in our implementation. I
> think it's all right, because the sigcomp message is 160
> bytes long, thus available cpb = (1000 + 8 * 160) * 16 =
> 36480 < 66327 that the execution of the whole test costs. The
> result is decompression failure when trying to execute the 3rd SHA-1.
> I suggest that this should also be corrected in the next
> draft that it could be executed with default cpb.
>
> BR/Zacco
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
> 
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Fri Jan 17 09:55:43 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24228
	for <rohc-archive@odin.ietf.org>; Fri, 17 Jan 2003 09:55:43 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0HFBLl05956
	for rohc-archive@odin.ietf.org; Fri, 17 Jan 2003 10:11:21 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HFBLJ05953
	for <rohc-web-archive@optimus.ietf.org>; Fri, 17 Jan 2003 10:11:21 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24209
	for <rohc-web-archive@ietf.org>; Fri, 17 Jan 2003 09:55:12 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HFBBJ05943;
	Fri, 17 Jan 2003 10:11:11 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HFAGJ05886
	for <rohc@optimus.ietf.org>; Fri, 17 Jan 2003 10:10:16 -0500
Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24177
	for <rohc@ietf.org>; Fri, 17 Jan 2003 09:54:07 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <CN3C0V8V>; Fri, 17 Jan 2003 14:57:28 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F192@rsys002a.roke.co.uk>
From: "Price, Richard" <richard.price@roke.co.uk>
To: "'Lajos Zaccomer (ETH)'" <Lajos.Zaccomer@eth.ericsson.se>, rohc@ietf.org
Subject: RE: [rohc] Torture test - 2.4. SHA-1
Date: Fri, 17 Jan 2003 14:57:28 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-2"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi,

That sounds like a good idea, so I'll make sure to add it for the
next version of the torture tests.

Regards,

Richard

> -----Original Message-----
> From: Lajos Zaccomer (ETH) [mailto:Lajos.Zaccomer@eth.ericsson.se]
> Sent: Friday, January 17, 2003 2:44 PM
> To: Price, Richard; rohc@ietf.org
> Subject: RE: [rohc] Torture test - 2.4. SHA-1
>
>
> Hi,
>
> I think it would be useful to describe a default test
> configuration at the beginning, and any alteration from that
> should be indicated before each test.
>
> BR/Zacco
>
> -----Original Message-----
> From: Price, Richard [mailto:richard.price@roke.co.uk]
> Sent: Friday, January 17, 2003 3:43 PM
> To: 'Lajos Zaccomer (ETH)'; rohc@ietf.org
> Subject: RE: [rohc] Torture test - 2.4. SHA-1
>
>
> Hi,
>
> For this particular test we deliberately use more than the
> default number of UDVM cycles. It's important to test the SHA-1
> instruction with the largest possible input size of 65535 bytes
> (e.g. to make sure that it doesn't cause any buffers to overflow),
> which means that the total cost of the test must be at least 2^16
> UDVM cycles.
>
> Would it be useful to have a note in the draft pointing out that
> since the test needs a total of 66327 UDVM cycles, it must be
> executed with a cpb of at least 32?
>
> Regards,
>
> Richard
>
> > -----Original Message-----
> > From: Lajos Zaccomer (ETH) [mailto:Lajos.Zaccomer@eth.ericsson.se]
> > Sent: Friday, January 17, 2003 11:08 AM
> > To: rohc@ietf.org
> > Subject: [rohc] Torture test - 2.4. SHA-1
> >
> >
> > Hi,
> >
> > The test of subject starts with 36480 available cpb (if
> > defaut cycles_per_bit = 16 is used) in our implementation. I
> > think it's all right, because the sigcomp message is 160
> > bytes long, thus available cpb = (1000 + 8 * 160) * 16 =
> > 36480 < 66327 that the execution of the whole test costs. The
> > result is decompression failure when trying to execute the
> 3rd SHA-1.
> > I suggest that this should also be corrected in the next
> > draft that it could be executed with default cpb.
> >
> > BR/Zacco
> > _______________________________________________
> > Rohc mailing list
> > Rohc@ietf.org
> > https://www1.ietf.org/mailman/listinfo/rohc
> >
> 
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Fri Jan 17 10:07:35 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24912
	for <rohc-archive@odin.ietf.org>; Fri, 17 Jan 2003 10:07:34 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0HFNDQ06627
	for rohc-archive@odin.ietf.org; Fri, 17 Jan 2003 10:23:13 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HFNDJ06624
	for <rohc-web-archive@optimus.ietf.org>; Fri, 17 Jan 2003 10:23:13 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24766
	for <rohc-web-archive@ietf.org>; Fri, 17 Jan 2003 10:07:03 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HFN0J06599;
	Fri, 17 Jan 2003 10:23:00 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HFKsJ06436
	for <rohc@optimus.ietf.org>; Fri, 17 Jan 2003 10:20:54 -0500
Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24661
	for <rohc@ietf.org>; Fri, 17 Jan 2003 10:04:44 -0500 (EST)
Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0HF85KV013867
	for <rohc@ietf.org>; Fri, 17 Jan 2003 16:08:05 +0100 (MET)
Received: by esealnt611.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <ZGNNNATW>; Fri, 17 Jan 2003 16:08:05 +0100
Message-ID: <F005CD411D18D3119C8F00508B0874800A144662@ehubunt100.eth.ericsson.se>
From: "Lajos Zaccomer (ETH)" <Lajos.Zaccomer@eth.ericsson.se>
To: rohc@ietf.org
Subject: RE: [rohc] Torture test - 2.10. INPUT-BITS
Date: Fri, 17 Jan 2003 16:06:32 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-2"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi,

My result differs from what is given in the draft

	0x0000 0002 0002 0013 0000 0003 001a 0038	

by the exclamation mark:
	
	0x0000 0002 0002 0013 (!) 0001 0006 000c 000d 0003

0x932e = (10)(0100)(110010)!(1)(110  

There input_bit_order = 1, i.e. P=1. Then it should input 1 bit of value 1 to the LSB of address 71, as a result of which the OUTPUT will be 0001.

Am I mistaken?

BR/Zacco

-----Original Message-----
From: Price, Richard [mailto:richard.price@roke.co.uk]
Sent: Friday, January 17, 2003 3:43 PM
To: 'Lajos Zaccomer (ETH)'; rohc@ietf.org
Subject: RE: [rohc] Torture test - 2.4. SHA-1


Hi,

For this particular test we deliberately use more than the
default number of UDVM cycles. It's important to test the SHA-1
instruction with the largest possible input size of 65535 bytes
(e.g. to make sure that it doesn't cause any buffers to overflow),
which means that the total cost of the test must be at least 2^16
UDVM cycles.

Would it be useful to have a note in the draft pointing out that
since the test needs a total of 66327 UDVM cycles, it must be
executed with a cpb of at least 32?

Regards,

Richard

> -----Original Message-----
> From: Lajos Zaccomer (ETH) [mailto:Lajos.Zaccomer@eth.ericsson.se]
> Sent: Friday, January 17, 2003 11:08 AM
> To: rohc@ietf.org
> Subject: [rohc] Torture test - 2.4. SHA-1
>
>
> Hi,
>
> The test of subject starts with 36480 available cpb (if
> defaut cycles_per_bit = 16 is used) in our implementation. I
> think it's all right, because the sigcomp message is 160
> bytes long, thus available cpb = (1000 + 8 * 160) * 16 =
> 36480 < 66327 that the execution of the whole test costs. The
> result is decompression failure when trying to execute the 3rd SHA-1.
> I suggest that this should also be corrected in the next
> draft that it could be executed with default cpb.
>
> BR/Zacco
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
> 

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



From mailnull@www1.ietf.org  Sun Jan 19 08:03:37 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19959
	for <rohc-archive@odin.ietf.org>; Sun, 19 Jan 2003 08:03:37 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0JDKCL01071
	for rohc-archive@odin.ietf.org; Sun, 19 Jan 2003 08:20:12 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0JDKCJ01068
	for <rohc-web-archive@optimus.ietf.org>; Sun, 19 Jan 2003 08:20:12 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19954
	for <rohc-web-archive@ietf.org>; Sun, 19 Jan 2003 08:03:06 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0JDJvJ01021;
	Sun, 19 Jan 2003 08:19:58 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0JDIRJ00997
	for <rohc@optimus.ietf.org>; Sun, 19 Jan 2003 08:18:27 -0500
Received: from maxwell3.pacific.net.sg (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19939
	for <rohc@ietf.org>; Sun, 19 Jan 2003 08:01:20 -0500 (EST)
Received: from oemcomputer ([210.24.89.174]) by maxwell3.pacific.net.sg
          with SMTP
          id <20030119130443.TONN3916.maxwell3.pacific.net.sg@oemcomputer>
          for <rohc@ietf.org>; Sun, 19 Jan 2003 21:04:43 +0800
Message-Id: <4.0.1.20030119205309.0091fbb0@gwserver.icr.a-star.edu.sg>
X-Sender: chankm@gwserver.icr.a-star.edu.sg
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Sun, 19 Jan 2003 21:06:13 +0800
To: rohc@ietf.org
From: Chan Kwang Mien <chankm@icr.a-star.edu.sg>
In-Reply-To: <76C92FBBFB58D411AE760090271ED41804A0F192@rsys002a.roke.co.
 uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [rohc] receiving uncompressed message
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

hi,

i would like to know what would happen if a SigComp-enabled host receives
uncompressed messages.
can the first 5 bits of the first byte (which is 11111) of a SigComp
message be used to detect whether the message is a SigComp message ? 
if it isn't then the message is an uncompressed message and would be passed
to the application without going through SigComp progressing. 
Does it make sense ?

Thanks!!

regards,
Kwang Mien


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



From mailnull@www1.ietf.org  Mon Jan 20 06:34:33 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16831
	for <rohc-archive@odin.ietf.org>; Mon, 20 Jan 2003 06:34:33 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0KBpYc13041
	for rohc-archive@odin.ietf.org; Mon, 20 Jan 2003 06:51:34 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KBpYJ13038
	for <rohc-web-archive@optimus.ietf.org>; Mon, 20 Jan 2003 06:51:34 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16811
	for <rohc-web-archive@ietf.org>; Mon, 20 Jan 2003 06:34:01 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KBpMJ13024;
	Mon, 20 Jan 2003 06:51:22 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KBo9J12978
	for <rohc@optimus.ietf.org>; Mon, 20 Jan 2003 06:50:09 -0500
Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16759
	for <rohc@ietf.org>; Mon, 20 Jan 2003 06:32:35 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <CN3C0X56>; Mon, 20 Jan 2003 11:35:58 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F193@rsys002a.roke.co.uk>
From: "Price, Richard" <richard.price@roke.co.uk>
To: "'Chan Kwang Mien'" <chankm@icr.a-star.edu.sg>, rohc@ietf.org
Subject: RE: [rohc] receiving uncompressed message
Date: Mon, 20 Jan 2003 11:35:57 -0000
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-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi Kwang Mien,

The first 5 bits of the SigComp header are included so that SigComp
messages can be distinguished from ordinary application messages.
If the bits aren't set to "11111" then the message is ignored by
SigComp and passed straight to the application.

Regards,

Richard

> -----Original Message-----
> From: Chan Kwang Mien [mailto:chankm@icr.a-star.edu.sg]
> Sent: Sunday, January 19, 2003 1:06 PM
> To: rohc@ietf.org
> Subject: [rohc] receiving uncompressed message
> 
> 
> hi,
> 
> i would like to know what would happen if a SigComp-enabled host receives
> uncompressed messages.
> can the first 5 bits of the first byte (which is 11111) of a SigComp
> message be used to detect whether the message is a SigComp message ? 
> if it isn't then the message is an uncompressed message and would be passed
> to the application without going through SigComp progressing. 
> Does it make sense ?
> 
> Thanks!!
> 
> regards,
> Kwang Mien
> 
> 
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
> 
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Mon Jan 20 06:54:18 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17229
	for <rohc-archive@odin.ietf.org>; Mon, 20 Jan 2003 06:54:18 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0KCBKD14599
	for rohc-archive@odin.ietf.org; Mon, 20 Jan 2003 07:11:20 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KCBKJ14596
	for <rohc-web-archive@optimus.ietf.org>; Mon, 20 Jan 2003 07:11:20 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17209
	for <rohc-web-archive@ietf.org>; Mon, 20 Jan 2003 06:53:47 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KCBCJ14584;
	Mon, 20 Jan 2003 07:11:12 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KCAwJ14561
	for <rohc@optimus.ietf.org>; Mon, 20 Jan 2003 07:10:58 -0500
Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17201
	for <rohc@ietf.org>; Mon, 20 Jan 2003 06:53:25 -0500 (EST)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0KBunKW020824
	for <rohc@ietf.org>; Mon, 20 Jan 2003 12:56:49 +0100 (MET)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <ZGNCFPHX>; Mon, 20 Jan 2003 12:56:40 +0100
Message-ID: <F005CD411D18D3119C8F00508B0874800A144669@ehubunt100.eth.ericsson.se>
From: "Lajos Zaccomer (ETH)" <Lajos.Zaccomer@eth.ericsson.se>
To: "'rohc@ietf.org'" <rohc@ietf.org>
Date: Mon, 20 Jan 2003 12:55:09 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-2"
Subject: [rohc] Torture Test - 2.12. INPUT-BYTES
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi,

I have problem with the output of test 2.12 (INPUT-BYTES):

The output area lies from 72 (byte_copy_left = 72) to 75 inclusive (byte_copy_right = 76). Initially input_bit_order = 0.

Let's see the execution of the code step by step:

* INPUT-BITS ($input_bit_order, result, end_of_message) 

this line inputs 0 bits, so the output is 0x0000 (OK)

* ADD ($input_bit_order, 2) 
  REMAINDER ($input_bit_order, 7)

input_bit_order = 2, i.e. H = 1 that does not impact the next INPUT-BYTE

* INPUT-BYTES ($input_bit_order, output_start, end_of_message)
  OUTPUT (output_start, $input_bit_order) 

inputs 2 bytes, so the output is 0x932E (OK)

* ADD ($input_bit_order, 1)

input_bit_order = 3, i.e. H = 1 and P = 1, then start again

* INPUT-BITS ($input_bit_order, result, end_of_message)

inputs 3 bits in MSB to LSB order (001), so the output is 0x0001 (OK)

* ADD ($input_bit_order, 2) 
  REMAINDER ($input_bit_order, 7)

input_bit_order = 5, i.e. F = 1, P = 1, but for INPUT-BYTES only P is interesting

* INPUT-BYTES ($input_bit_order, output_start, end_of_message)
  OUTPUT (output_start, $input_bit_order) 

The remaining 5 bits of AC are discarded. The 5 bytes read are: 8e 66 1b f6 8d. As the fifth bytes overwrites the first one in the memory, the output area contains 8d 66 1b f6.  The five output bytes should then be: 8d 66 1b f6 8d. The torture test doc instead says: b166 d86f b100 ...

Am I again mistaken?

BR/Zacco


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



From mailnull@www1.ietf.org  Mon Jan 20 08:34:50 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19668
	for <rohc-archive@odin.ietf.org>; Mon, 20 Jan 2003 08:34:50 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0KDpt820163
	for rohc-archive@odin.ietf.org; Mon, 20 Jan 2003 08:51:55 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KDptJ20160
	for <rohc-web-archive@optimus.ietf.org>; Mon, 20 Jan 2003 08:51:55 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19662
	for <rohc-web-archive@ietf.org>; Mon, 20 Jan 2003 08:34:19 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KDpeJ20151;
	Mon, 20 Jan 2003 08:51:41 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KDohJ20121
	for <rohc@optimus.ietf.org>; Mon, 20 Jan 2003 08:50:43 -0500
Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19618
	for <rohc@ietf.org>; Mon, 20 Jan 2003 08:33:07 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <CN3C0Y1K>; Mon, 20 Jan 2003 13:36:32 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED41804B885BA@rsys002a.roke.co.uk>
From: "Surtees, Abigail" <abigail.surtees@roke.co.uk>
To: "'Lajos Zaccomer (ETH)'" <Lajos.Zaccomer@eth.ericsson.se>, rohc@ietf.org
Subject: RE: [rohc] Torture test - 2.10. INPUT-BITS
Date: Mon, 20 Jan 2003 13:36:31 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-2"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi Zacco,

The original message is 0x932e ac71 = 10010011 00101110  10101100 01110001

As you say the first bits read are split as follows (10)(0100)(110010) which leaves 4 bits of the 2nd byte remaining.  At this point P changes to 1 which means that the remainder of the second byte (that is 1110) should be thrown away, according to section 8.2.  Then 1 bit is read from the 3rd byte but from the least significant bits first - that is 1010110(0) so the bit read is 0.  The next time 3 bits are read 1010(110)(0) and so on.

Best regards,

Abbie


>
>My result differs from what is given in the draft
>
>	0x0000 0002 0002 0013 0000 0003 001a 0038	
>
>by the exclamation mark:
>	
>	0x0000 0002 0002 0013 (!) 0001 0006 000c 000d 0003
>
>0x932e = (10)(0100)(110010)!(1)(110  
>
>There input_bit_order = 1, i.e. P=1. Then it should input 1 
>bit of value 1 to the LSB of address 71, as a result of which 
>the OUTPUT will be 0001.
>
>Am I mistaken?
>
>BR/Zacco
>
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Mon Jan 20 08:48:20 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20144
	for <rohc-archive@odin.ietf.org>; Mon, 20 Jan 2003 08:48:20 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0KE5PQ20831
	for rohc-archive@odin.ietf.org; Mon, 20 Jan 2003 09:05:25 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KE5PJ20828
	for <rohc-web-archive@optimus.ietf.org>; Mon, 20 Jan 2003 09:05:25 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20124
	for <rohc-web-archive@ietf.org>; Mon, 20 Jan 2003 08:47:49 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KE5BJ20804;
	Mon, 20 Jan 2003 09:05:11 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KE4KJ20767
	for <rohc@optimus.ietf.org>; Mon, 20 Jan 2003 09:04:20 -0500
Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20099
	for <rohc@ietf.org>; Mon, 20 Jan 2003 08:46:43 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <CN3C0YFQ>; Mon, 20 Jan 2003 13:50:08 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED41804B885BB@rsys002a.roke.co.uk>
From: "Surtees, Abigail" <abigail.surtees@roke.co.uk>
To: "'Lajos Zaccomer (ETH)'" <Lajos.Zaccomer@eth.ericsson.se>,
        "'rohc@ietf.org'" <rohc@ietf.org>
Subject: RE: [rohc] Torture Test - 2.12. INPUT-BYTES
Date: Mon, 20 Jan 2003 13:50:08 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-2"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi Zacco,

<snip>
>input_bit_order = 5, i.e. F = 1, P = 1, but for INPUT-BYTES 
>only P is interesting
>
>* INPUT-BYTES ($input_bit_order, output_start, end_of_message)
>  OUTPUT (output_start, $input_bit_order) 
>
>The remaining 5 bits of AC are discarded. The 5 bytes read 
>are: 8e 66 1b f6 8d. As the fifth bytes overwrites the first 
>one in the memory, the output area contains 8d 66 1b f6.  The 
>five output bytes should then be: 8d 66 1b f6 8d. The torture 
>test doc instead says: b166 d86f b100 ...
>
Input bytes doesn't take any account of input_bit_order.  In particular, it takes no notice of the P bit.
The 5 bits of AC are discarded, as you say.  Then the next 5 bytes of the message are read straight in - that is 71 66 d8 6f b1 from the compressed message.  Then the output area contains b1 66 d8 6f and the output becomes b1 66 d8 6f b1.  In using INPUT-BYTES there is no swapping the order of the bits.  

I hope this helps.

Best regards,

Abbie

>Am I again mistaken?
>
>BR/Zacco
>
>
>_______________________________________________
>Rohc mailing list
>Rohc@ietf.org
>https://www1.ietf.org/mailman/listinfo/rohc
>
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Mon Jan 20 16:05:29 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00874
	for <rohc-archive@odin.ietf.org>; Mon, 20 Jan 2003 16:05:29 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0KLMfw15080
	for rohc-archive@odin.ietf.org; Mon, 20 Jan 2003 16:22:41 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KLMfJ15077
	for <rohc-web-archive@optimus.ietf.org>; Mon, 20 Jan 2003 16:22:41 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00808
	for <rohc-web-archive@ietf.org>; Mon, 20 Jan 2003 16:04:57 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KLMRJ15029;
	Mon, 20 Jan 2003 16:22:27 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KLJrJ14870
	for <rohc@optimus.ietf.org>; Mon, 20 Jan 2003 16:19:53 -0500
Received: from marjan.fesb.hr (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00650
	for <rohc@ietf.org>; Mon, 20 Jan 2003 16:02:09 -0500 (EST)
Received: (from root@localhost)
	by marjan.fesb.hr (8.12.3/8.12.1/Debian -5) id h0KL5Xbm030766
	for rohc@ietf.org; Mon, 20 Jan 2003 22:05:33 +0100
Received: from fesb.hr (demorgan.bit.fesb.hr [161.53.169.245])
	(authenticated bits=0)
	by marjan.fesb.hr (8.12.3/8.12.1/Debian -5) with ESMTP id h0KL5VrM030759
	for <rohc@ietf.org>; Mon, 20 Jan 2003 22:05:31 +0100
Message-ID: <3E2C6546.9020702@fesb.hr>
Date: Mon, 20 Jan 2003 22:08:22 +0100
From: Julije Ozegovic <julije@fesb.hr>
Organization: FESB Split
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en, hr
MIME-Version: 1.0
To: rohc <rohc@ietf.org>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS perl-11
Content-Transfer-Encoding: 7bit
Subject: [rohc] EPIC-Lite software released version 1.00
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

ROHCers,

EPIC-Lite implementation release 1.00 is available on

      http://www.epic-lite.org

Program is based on

      draft-ietf-rohc-epic-lite-01.txt (already expired).

Test files are included for reference.

Best regards,
Julije Ozegovic

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



From mailnull@www1.ietf.org  Tue Jan 21 03:24:11 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23516
	for <rohc-archive@odin.ietf.org>; Tue, 21 Jan 2003 03:24:11 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0L8fdH30965
	for rohc-archive@odin.ietf.org; Tue, 21 Jan 2003 03:41:39 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L8fcJ30962
	for <rohc-web-archive@optimus.ietf.org>; Tue, 21 Jan 2003 03:41:38 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23509
	for <rohc-web-archive@ietf.org>; Tue, 21 Jan 2003 03:23:40 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L8fRJ30951;
	Tue, 21 Jan 2003 03:41:27 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L8efJ30917
	for <rohc@optimus.ietf.org>; Tue, 21 Jan 2003 03:40:41 -0500
Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23501
	for <rohc@ietf.org>; Tue, 21 Jan 2003 03:22:41 -0500 (EST)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0L8Q7Av021561;
	Tue, 21 Jan 2003 09:26:07 +0100 (MET)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <DLW9KXKN>; Tue, 21 Jan 2003 09:26:07 +0100
Message-ID: <F005CD411D18D3119C8F00508B0874800A14466E@ehubunt100.eth.ericsson.se>
From: "Lajos Zaccomer (ETH)" <Lajos.Zaccomer@eth.ericsson.se>
To: "'Surtees, Abigail'" <abigail.surtees@roke.co.uk>,
        "'rohc@ietf.org'"
	 <rohc@ietf.org>
Subject: RE: [rohc] Torture Test - 2.12. INPUT-BYTES
Date: Tue, 21 Jan 2003 09:24:12 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0L8efJ30918
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Hi,

Thanx for the answers! INPUT-BITS all right now.
However, I have doubts on what you said about INPUT-BYTES. The RFC says (page 31): "The P-bit controls the order in which bits are passed from the dispatcher to the INPUT instructions." As one byte is comprised of 8 bits, it is quite straightforward to understand this way. I must say that the RFC is again not clear enough!

Also, check this mail on the list:

From: "West, Mark (ITN)" <mark.a.west@roke.co.uk>
To: Zoltan Barczikay <Zoltan.Barczikay@eth.ericsson.se>
Cc: rohc@ietf.org
Subject: Re: [rohc] SigComp: input_bit_order question...

Zoltán's mail stated that P applies to INPUT-BYTES as well, which was not objected by Mark or anybody else.

According to the RFC, both explanations seem acceptable to me. But what is the truth?

BR/Zacco


-----Original Message-----
From: Surtees, Abigail [mailto:abigail.surtees@roke.co.uk]
Sent: Monday, January 20, 2003 2:50 PM
To: 'Lajos Zaccomer (ETH)'; 'rohc@ietf.org'
Subject: RE: [rohc] Torture Test - 2.12. INPUT-BYTES


Hi Zacco,

<snip>
>input_bit_order = 5, i.e. F = 1, P = 1, but for INPUT-BYTES 
>only P is interesting
>
>* INPUT-BYTES ($input_bit_order, output_start, end_of_message)
>  OUTPUT (output_start, $input_bit_order) 
>
>The remaining 5 bits of AC are discarded. The 5 bytes read 
>are: 8e 66 1b f6 8d. As the fifth bytes overwrites the first 
>one in the memory, the output area contains 8d 66 1b f6.  The 
>five output bytes should then be: 8d 66 1b f6 8d. The torture 
>test doc instead says: b166 d86f b100 ...
>
Input bytes doesn't take any account of input_bit_order.  In particular, it takes no notice of the P bit.
The 5 bits of AC are discarded, as you say.  Then the next 5 bytes of the message are read straight in - that is 71 66 d8 6f b1 from the compressed message.  Then the output area contains b1 66 d8 6f and the output becomes b1 66 d8 6f b1.  In using INPUT-BYTES there is no swapping the order of the bits.  

I hope this helps.

Best regards,

Abbie

>Am I again mistaken?
>
>BR/Zacco
>
>
>_______________________________________________
>Rohc mailing list
>Rohc@ietf.org
>https://www1.ietf.org/mailman/listinfo/rohc
>
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Wed Jan 22 02:20:54 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10041
	for <rohc-archive@odin.ietf.org>; Wed, 22 Jan 2003 02:20:54 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0M7cnR31479
	for rohc-archive@odin.ietf.org; Wed, 22 Jan 2003 02:38:49 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M7cnJ31476
	for <rohc-web-archive@optimus.ietf.org>; Wed, 22 Jan 2003 02:38:49 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09369
	for <rohc-web-archive@ietf.org>; Wed, 22 Jan 2003 02:20:23 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M7cWJ31467;
	Wed, 22 Jan 2003 02:38:33 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LKvkJ15344
	for <rohc@optimus.ietf.org>; Tue, 21 Jan 2003 15:57:46 -0500
Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11458
	for <rohc@ietf.org>; Tue, 21 Jan 2003 15:39:33 -0500 (EST)
Received: from zrc2c001.us.nortel.com (zrc2c001.us.nortel.com [47.103.121.31])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0LKhC616923
	for <rohc@ietf.org>; Tue, 21 Jan 2003 14:43:12 -0600 (CST)
Received: from zrc2c009.us.nortel.com ([47.103.120.49]) by zrc2c001.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id ZC52X89C; Tue, 21 Jan 2003 14:42:59 -0600
Received: from iqmail.net (chowdury-2.us.nortel.com [47.103.84.30]) by zrc2c009.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id VSN2SDSW; Tue, 21 Jan 2003 14:42:58 -0600
Message-ID: <3E2DAFC2.40104@iqmail.net>
Date: Tue, 21 Jan 2003 14:38:26 -0600
X-Sybari-Space: 00000000 00000000 00000000
From: Kuntal Chowdhury <kuntal@iqmail.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: rohc@ietf.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [rohc] comment on ROHC-TCP
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hello folks,
I think we need to separate the issues between a single short lived TCP 
connection (rare event) from multiple (near-)simultaneous short lived
TCP connections. The reason being, the scenario of single short lived 
TCP connection applies to both HTTP1.0 and 1.1, however the scenario of 
multiple short lived (near-)simultaneous TCP connections may be a 
problem with HTTP1.0 only (HTTP1.1 solves the problem with persistence 
and pipelining as default behavior). Therefore I suggest, we split 
section 3.3 to discuss single short lived and multiple 
(near-)simultaneous short lived TCP connections separately.

Thoughts?

-Kuntal

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



From mailnull@www1.ietf.org  Thu Jan 23 04:03:26 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00799
	for <rohc-archive@odin.ietf.org>; Thu, 23 Jan 2003 04:03:26 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0N9Lrf08838
	for rohc-archive@odin.ietf.org; Thu, 23 Jan 2003 04:21:53 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N9LqJ08833
	for <rohc-web-archive@optimus.ietf.org>; Thu, 23 Jan 2003 04:21:52 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00790
	for <rohc-web-archive@ietf.org>; Thu, 23 Jan 2003 04:02:55 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N9LVJ08814;
	Thu, 23 Jan 2003 04:21:32 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N9K7J08750
	for <rohc@optimus.ietf.org>; Thu, 23 Jan 2003 04:20:07 -0500
Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00750
	for <rohc@ietf.org>; Thu, 23 Jan 2003 04:01:09 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <CN3C08AW>; Thu, 23 Jan 2003 09:04:33 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED41804B885CC@rsys002a.roke.co.uk>
From: "Surtees, Abigail" <abigail.surtees@roke.co.uk>
To: "'Lajos Zaccomer (ETH)'" <Lajos.Zaccomer@eth.ericsson.se>,
        "'rohc@ietf.org'" <rohc@ietf.org>
Subject: RE: [rohc] Torture Test - 2.12. INPUT-BYTES
Date: Thu, 23 Jan 2003 09:04:23 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0N9K8J08751
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Hi Zacco,

The INPUT-BITS and INPUT-HUFFMAN sections both reference section 8.2 (the input_bit_order section) whereas the INPUT-BYTES does not.  The reference you make to page 31 is written within section 8.2, the second paragraph of which begins 'Note that the INPUT-BITS and INPUT-HUFFMAN instructions receive a stream of individual compressed bits...' and doesn't mention INPUT-BYTES.

I think the intention of the authors was that the P bit should not affect INPUT-BYTES but I think it could be made clearer.  

Best Regards,

Abbie



>-----Original Message-----
>From: Lajos Zaccomer (ETH) [mailto:Lajos.Zaccomer@eth.ericsson.se]
>Sent: 21 January 2003 08:24
>To: Surtees, Abigail; 'rohc@ietf.org'
>Subject: RE: [rohc] Torture Test - 2.12. INPUT-BYTES
>
>
>Hi,
>
>Thanx for the answers! INPUT-BITS all right now.
>However, I have doubts on what you said about INPUT-BYTES. The 
>RFC says (page 31): "The P-bit controls the order in which 
>bits are passed from the dispatcher to the INPUT 
>instructions." As one byte is comprised of 8 bits, it is quite 
>straightforward to understand this way. I must say that the 
>RFC is again not clear enough!
>
>Also, check this mail on the list:
>
>From: "West, Mark (ITN)" <mark.a.west@roke.co.uk>
>To: Zoltan Barczikay <Zoltan.Barczikay@eth.ericsson.se>
>Cc: rohc@ietf.org
>Subject: Re: [rohc] SigComp: input_bit_order question...
>
>Zoltán's mail stated that P applies to INPUT-BYTES as well, 
>which was not objected by Mark or anybody else.
>
>According to the RFC, both explanations seem acceptable to me. 
>But what is the truth?
>
>BR/Zacco
>
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Thu Jan 23 07:02:09 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03627
	for <rohc-archive@odin.ietf.org>; Thu, 23 Jan 2003 07:02:09 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0NCKcR19532
	for rohc-archive@odin.ietf.org; Thu, 23 Jan 2003 07:20:38 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NCKcJ19529
	for <rohc-web-archive@optimus.ietf.org>; Thu, 23 Jan 2003 07:20:38 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03616
	for <rohc-web-archive@ietf.org>; Thu, 23 Jan 2003 07:01:38 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NCJOJ19471;
	Thu, 23 Jan 2003 07:19:24 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NCImJ19452
	for <rohc@optimus.ietf.org>; Thu, 23 Jan 2003 07:18:48 -0500
Received: from igate2.vodafone.co.uk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03583
	for <rohc@ietf.org>; Thu, 23 Jan 2003 06:59:46 -0500 (EST)
Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id MAA16795; Thu, 23 Jan 2003 12:03:12 GMT
Received: from putney.vfl.vodafone (putney [10.33.112.118])
	by mailguard1 (4.6.1.123) with ESMTP id 
	for <rohc@ietf.org>; Thu, 23 Jan 2003 12:03:39 GMT
Received: from ukwmxc02.vf-uk.internal.vodafone.com ([10.33.126.170]) by putney.vfl.vodafone with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id YL9A7NGG; Thu, 23 Jan 2003 12:02:42 -0000
Received: from ukwmxc04.vf-uk.internal.vodafone.com ([10.33.126.173]) by ukwmxc02.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.4453);
	 Thu, 23 Jan 2003 12:01:54 +0000
Received: from ukwmxm01.vf-uk.internal.vodafone.com ([10.33.126.162]) by ukwmxc04.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.4453);
	 Thu, 23 Jan 2003 12:01:54 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
Date: Thu, 23 Jan 2003 12:01:54 -0000
Message-ID: <6FC554FA1F33BE4C9AC844FC3B3B71280D1489@UKWMXM01>
Thread-Topic: Question about Channel Parameters and U-Mode
Thread-Index: AcLC11Ku6I50KS6oEdebQABQBFRDqA==
From: "Holmes, Matthew, CND Tech Dev, VF UK" <Matthew.Holmes@gb.vodafone.co.uk>
To: <rohc@ietf.org>
X-OriginalArrivalTime: 23 Jan 2003 12:01:54.0648 (UTC) FILETIME=[38CC8580:01C2C2D7]
MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122)
Content-Type: text/plain;	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0NCImJ19453
Subject: [rohc] Question about Channel Parameters and U-Mode
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Hi All

I'm a bit confused about how channel parameters are negotiated in U-Mode. If no feedback path is available then U-Mode would be used.
Can some one explain what happens with the channel parameters in this case? 
How would something like the PROFILES parameter be sent to the compressor? 
Although feedback is not required for U-Mode is a two-way link mandatory for the link establishment?

Any help would be appreciated,

Thank you

Matthew Holmes


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



From mailnull@www1.ietf.org  Thu Jan 23 07:05:44 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03705
	for <rohc-archive@odin.ietf.org>; Thu, 23 Jan 2003 07:05:44 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0NCOE119703
	for rohc-archive@odin.ietf.org; Thu, 23 Jan 2003 07:24:14 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NCODJ19700
	for <rohc-web-archive@optimus.ietf.org>; Thu, 23 Jan 2003 07:24:13 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03702
	for <rohc-web-archive@ietf.org>; Thu, 23 Jan 2003 07:05:13 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NCO2J19683;
	Thu, 23 Jan 2003 07:24:02 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NCNGJ19662
	for <rohc@optimus.ietf.org>; Thu, 23 Jan 2003 07:23:16 -0500
Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03673
	for <rohc@ietf.org>; Thu, 23 Jan 2003 07:04:15 -0500 (EST)
Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0NC7fAx023272;
	Thu, 23 Jan 2003 13:07:41 +0100 (MET)
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <DLVCJYQF>; Thu, 23 Jan 2003 13:07:41 +0100
Message-ID: <A943FD84BD9ED41193460008C791805003E324FE@ESEALNT419.al.sw.ericsson.se>
From: "Lars-Erik Jonsson (EAB)" <Lars-Erik.Jonsson@epl.ericsson.se>
To: "'Holmes, Matthew, CND Tech Dev, VF UK'"
	 <Matthew.Holmes@gb.vodafone.co.uk>,
        rohc@ietf.org
Subject: RE: [rohc] Question about Channel Parameters and U-Mode
Date: Thu, 23 Jan 2003 12:57:26 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Matthew,

According to RFC 3095 section 4.1 (page 19):

   Negotiation

      In addition to the packet handling mechanisms above, the link
      layer MUST provide a way to negotiate header compression
      parameters, see also section 5.1.1.  (For unidirectional links,
      this negotiation may be performed out-of-band or even a priori.)


BR
/L-E



> -----Original Message-----
> From: Holmes, Matthew, CND Tech Dev, VF UK
> [mailto:Matthew.Holmes@gb.vodafone.co.uk]
> Sent: den 23 januari 2003 13:02
> To: rohc@ietf.org
> Subject: [rohc] Question about Channel Parameters and U-Mode
> 
> 
> Hi All
> 
> I'm a bit confused about how channel parameters are 
> negotiated in U-Mode. If no feedback path is available then 
> U-Mode would be used.
> Can some one explain what happens with the channel parameters 
> in this case? 
> How would something like the PROFILES parameter be sent to 
> the compressor? 
> Although feedback is not required for U-Mode is a two-way 
> link mandatory for the link establishment?
> 
> Any help would be appreciated,
> 
> Thank you
> 
> Matthew Holmes
> 
> 
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
> 
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Thu Jan 23 07:40:00 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04439
	for <rohc-archive@odin.ietf.org>; Thu, 23 Jan 2003 07:40:00 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0NCwUR21786
	for rohc-archive@odin.ietf.org; Thu, 23 Jan 2003 07:58:30 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NCwUJ21783
	for <rohc-web-archive@optimus.ietf.org>; Thu, 23 Jan 2003 07:58:30 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04430
	for <rohc-web-archive@ietf.org>; Thu, 23 Jan 2003 07:39:28 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NCwHJ21772;
	Thu, 23 Jan 2003 07:58:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NCvwJ21736
	for <rohc@optimus.ietf.org>; Thu, 23 Jan 2003 07:57:58 -0500
Received: from dog.topology.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04409
	for <rohc@ietf.org>; Thu, 23 Jan 2003 07:38:54 -0500 (EST)
Received: (from akenning@localhost)
	by dog.topology.org (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id h0NCgCN15099;
	Thu, 23 Jan 2003 23:12:12 +1030
X-Authentication-Warning: dog.topology.org: akenning set sender to ak.rohc@topology.org using -f
Date: Thu, 23 Jan 2003 23:12:12 +1030
From: Alan Kennington <ak.rohc@topology.org>
To: "Lars-Erik Jonsson (EAB)" <Lars-Erik.Jonsson@epl.ericsson.se>
Cc: rohc@ietf.org, Alan Kennington  <ak.rohc@topology.org>
Subject: Re: [rohc] Question about Channel Parameters and U-Mode
Message-ID: <20030123231212.A15041@dog.topology.org>
Reply-To: Alan Kennington  <ak.rohc@topology.org>
References: <A943FD84BD9ED41193460008C791805003E324FE@ESEALNT419.al.sw.ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.12i
In-Reply-To: <A943FD84BD9ED41193460008C791805003E324FE@ESEALNT419.al.sw.ericsson.se>; from Lars-Erik.Jonsson@epl.ericsson.se on Thu, Jan 23, 2003 at 12:57:26PM +0100
X-PGP-Key: http://www.topology.org/ak/key_ak2.asc
X-PGP-Key-Fingerprint: 8A7B 7A8E 1C02 8298 579F 1860 7D56 121B D363 329E
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

On Thu, Jan 23, 2003 at 12:57:26PM +0100, Lars-Erik Jonsson (EAB) wrote:
> Matthew,
> 
> According to RFC 3095 section 4.1 (page 19):
> 
>    Negotiation
> 
>       In addition to the packet handling mechanisms above, the link
>       layer MUST provide a way to negotiate header compression
>       parameters, see also section 5.1.1.  (For unidirectional links,
>       this negotiation may be performed out-of-band or even a priori.)
> 
> 
> BR
> /L-E

This does raise the question as to whether, for the sake of
better standardisation, there should be a specified preferred a-priori
set of parameters for each link type.
For example, for PPP links, rfc3241, these parameters could be assumed:

MAX_CID		15
MRRU		0
MAX_HEADER	168
PROFILES	0x0000, 0x0001, 0x0002 

Then if you had two different brands of ROHC/PPP software from
different vendors, you should be able to get them interworking
on a simplex link without sending round the carrier pigeon.

In fact, on a simplex link, the above parameters are only relevant
to _ability_ to receive something - they do not affect the actual
interpretation of anything.

Therefore I conclude that, more or less, parameter negotiation is
superfluous on a simplex link, and maybe for duplex also,
if you assume that all implementations wake up as above or with
larger numbers or sets.
All you really need to know is that the other side has an ROHC implementation.

A fly in the ointment here is the fact that the PPP standard says
categorically (RFC 1661, p.1):

    The point-to-point Protocol is designed for simple links which
    transport packets between two peers. These links provide full-duplex
    simultaneous bi-directional operation, ...
 
PPP implementations (such as linux) seems to not allow a single
packet to pass until at least one LCP packet is received.
Therefore the problem lies in PPP, not in ROHC/PPP.

Maybe a set of standard out-of-the-box null-negotiation parameters
could be specified in RFC 3241 to take care of simplex links!?

Cheers,
Alan Kennington.

--------------------------------------------------------------------
    name: Dr. Alan Kennington
 website: http://www.topology.org/
    city: Adelaide, South Australia
  coords: 138.59 E, 34.88 S
timezone: UTC+1030 http://www.topology.org/site/timezone.html
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Thu Jan 23 07:49:37 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04949
	for <rohc-archive@odin.ietf.org>; Thu, 23 Jan 2003 07:49:36 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0ND87k22954
	for rohc-archive@odin.ietf.org; Thu, 23 Jan 2003 08:08:07 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ND87J22951
	for <rohc-web-archive@optimus.ietf.org>; Thu, 23 Jan 2003 08:08:07 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04942
	for <rohc-web-archive@ietf.org>; Thu, 23 Jan 2003 07:49:05 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ND7uJ22936;
	Thu, 23 Jan 2003 08:07:56 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ND5nJ22156
	for <rohc@optimus.ietf.org>; Thu, 23 Jan 2003 08:05:49 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04788;
	Thu, 23 Jan 2003 07:46:48 -0500 (EST)
Message-Id: <200301231246.HAA04788@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rohc@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Thu, 23 Jan 2003 07:46:48 -0500
Subject: [rohc] I-D ACTION:draft-ietf-rohc-ip-only-01.txt
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Robust Header Compression Working Group of the IETF.

	Title		: RObust Header Compression (ROHC): A Compression 
                          Profile for IP
	Author(s)	: L. Jonsson
	Filename	: draft-ietf-rohc-ip-only-01.txt
	Pages		: 8
	Date		: 2003-1-22
	
The original RObust Header Compression (ROHC) RFC, RFC 3095, defines
a framework for header compression, along with compression protocols
(profiles) for IP/UDP/RTP, IP/ESP, IP/UDP, and also a profile for
uncompressed packet streams. However, no profile was defined for
compression of IP only, which has been identified as a missing piece
in RFC 3095. This document defines a ROHC compression profile for IP,
similar to the IP/UDP profile defined by RFC 3095, but simplified to
exclude UDP, and enhanced to compress IP header chains of arbitrary
length.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rohc-ip-only-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-rohc-ip-only-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-rohc-ip-only-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-1-22111505.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-rohc-ip-only-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-rohc-ip-only-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-1-22111505.I-D@ietf.org>

--OtherAccess--

--NextPart--


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



From mailnull@www1.ietf.org  Thu Jan 23 08:37:59 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07056
	for <rohc-archive@odin.ietf.org>; Thu, 23 Jan 2003 08:37:59 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0NDuVK26244
	for rohc-archive@odin.ietf.org; Thu, 23 Jan 2003 08:56:31 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NDuUJ26241
	for <rohc-web-archive@optimus.ietf.org>; Thu, 23 Jan 2003 08:56:30 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07048
	for <rohc-web-archive@ietf.org>; Thu, 23 Jan 2003 08:37:28 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NDuKJ26225;
	Thu, 23 Jan 2003 08:56:20 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NDtMJ26158
	for <rohc@optimus.ietf.org>; Thu, 23 Jan 2003 08:55:22 -0500
Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07010
	for <rohc@ietf.org>; Thu, 23 Jan 2003 08:36:19 -0500 (EST)
Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0NDddKW008039;
	Thu, 23 Jan 2003 14:39:39 +0100 (MET)
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <DLVCK45H>; Thu, 23 Jan 2003 14:39:38 +0100
Message-ID: <A943FD84BD9ED41193460008C791805003E324FF@ESEALNT419.al.sw.ericsson.se>
From: "Lars-Erik Jonsson (EAB)" <Lars-Erik.Jonsson@epl.ericsson.se>
To: "'Alan Kennington'" <ak.rohc@topology.org>
Cc: rohc@ietf.org
Subject: RE: [rohc] Question about Channel Parameters and U-Mode
Date: Thu, 23 Jan 2003 14:29:20 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Alan,

> This does raise the question as to whether, for the sake of
> better standardisation, there should be a specified preferred
> a-priori set of parameters for each link type.

Yes, this could be appropriate for simplex links. However, we
do not handle such link specific issues in the IETF. We do
define the operation for PPP, but other bodies have to handle
this for other links. That is what we have done in ROHC, in
the same way as for previous compression schemes.


> For example, for PPP links, rfc3241, these parameters could 
> be assumed:
> 
> MAX_CID		15
> MRRU		0
> MAX_HEADER	168
> PROFILES	0x0000, 0x0001, 0x0002 

Well, I am not sure one can specify a default for PROFILES. If
there is a way no negotiate, one should absolutely use that.

 
> Then if you had two different brands of ROHC/PPP software from
> different vendors, you should be able to get them interworking
> on a simplex link without sending round the carrier pigeon.

Hmmm...PPP is not for simplex links...so the above suggestion does
not really compile. But I agree that this approach would be a
candidate for simplex links. That is what is meant with a priori,
as suggested by 3095.

> Therefore I conclude that, more or less, parameter negotiation is
> superfluous on a simplex link, and maybe for duplex also,
> if you assume that all implementations wake up as above or with
> larger numbers or sets.
> All you really need to know is that the other side has an 
> ROHC implementation.

You would still have to negotiate (at least) profiles, and it is
useful to have negotiation also for the other parameters. In any
case, this is a link-specific issue that must be addressed for
each link type. For PPP, all parameters are negotiated, as defined
by RFC 3241.


> Maybe a set of standard out-of-the-box null-negotiation parameters
> could be specified in RFC 3241 to take care of simplex links!?

RFC 3241 defines ROHC-over-PPP, which is for duplex links. 


To summarize, this is an issue for bodies responsible of simplex
links where one wants to use ROHC, it is not within our scope.

Cheers,
/L-E

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



From mailnull@www1.ietf.org  Thu Jan 23 12:01:01 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13294
	for <rohc-archive@odin.ietf.org>; Thu, 23 Jan 2003 12:01:01 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0NHJaw08906
	for rohc-archive@odin.ietf.org; Thu, 23 Jan 2003 12:19:36 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NHJaJ08903
	for <rohc-web-archive@optimus.ietf.org>; Thu, 23 Jan 2003 12:19:36 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13275
	for <rohc-web-archive@ietf.org>; Thu, 23 Jan 2003 12:00:30 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NHJKJ08870;
	Thu, 23 Jan 2003 12:19:20 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NHH5J08648
	for <rohc@optimus.ietf.org>; Thu, 23 Jan 2003 12:17:05 -0500
Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13198
	for <rohc@ietf.org>; Thu, 23 Jan 2003 11:57:58 -0500 (EST)
Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0NH1NKV009888;
	Thu, 23 Jan 2003 18:01:23 +0100 (MET)
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <DLVCMKFG>; Thu, 23 Jan 2003 18:01:23 +0100
Message-ID: <A943FD84BD9ED41193460008C791805003E32507@ESEALNT419.al.sw.ericsson.se>
From: "Lars-Erik Jonsson (EAB)" <Lars-Erik.Jonsson@epl.ericsson.se>
To: ROHC WG <rohc@ietf.org>,
        "Juergen Quittek (E-mail)"
	 <quittek@ccrle.nec.de>
Subject: RE: [rohc] WG last-call for ROHC MIB and related documents
Date: Thu, 23 Jan 2003 17:51:06 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi all,

I have reviewed the MIB document and it looks overall very
good. I have noticed the following that should be addressed:

- The document should have an IANA Considerations section for the
  new IANA registrations, both a listing of the new registrations
  and a "TO BE REMOVED BEFORE PUBLICATION" request text addressed
  to the IANA).

- The TOC is a little bit hard to read. It would be clearer by
  writing e.g. "2.  The SNMP..." instead or "2 The SNMP..."

- Last paragraph above section 4.1. should be rewritten to be
  clearer about which two MIB's are referred to.

- In section 4.1.2, clarify that "feedback for" only applies if
  the channel is actually transmitting any feedback, either
  as a dedicated feedback channel or interspersed/piggybacked.

- In section 4.1.4, title of first bullet list, should be
  "attributes", not "attribute".

- In section 4.1.4, statistics list, fourth bullet, should say
  "context", not "conrtext".

- In section 4.1.4, statistics list, "mean packet size" bullets
  (both), should say "packet size" and "compressed packets"
  instead of "packets size" and "packets".

- In section 4.1.4, statistics list, "mean header size" bullets
  (both), should say "passing" instead of "in".

- On page 11, "rohcChannelType", DESCRIPTION, missing "m" on 
  "might".

- On page 12, "rohcInstanceTable", DESCRIPTION, end of
  description should read "used for each ROHC instance" instead
  of "used for ROHC".

- On page 15, "rohcInstanceLargeCIDs", DESCRIPTION, should say
  "returns true if the embedded" instead of
  "returns true, the embedded"

- On page 15, "rohcInstanceMRRU", DESCRIPTION, first sentence
  has no end, ends with "according to."

- On page 15, "rohcInstanceContextStorageTime", DESCRIPTION,
  refers to "rohcInstanceContextExpireTime", which does not
  exist. Should probably say "rohcInstanceContextStorageTime".

- On page 16, "rohcInstancePackets", DESCRIPTION, something is
  missing in the sentence "Counter of passing this instance".

- The most significant problem found is about the ProfileTable,
  page 17-18. Both compressor and decompressor instances have
  support for certain profiles, and one should be able to see
  which profiles are supported and the properties of the
  various profile implementations, independent of if the
  instance is a compressor or a decompressor. What should also
  be readable would be information of which profiles are
  active, i.e. have been negotiated to be used on an instance.
  As we have noticed during the last year, RFC 3095 is rather
  confusing in this regard. So, I would propose the following:

  1) Change the DESCRIPTION for "rohcProfileTable" to:
     "This table lists a set of profiles supported by the instance."

  2) Change the DESCRIPTION for "rohcProfileEntry" to:
     "An entry describing a particular profile supported by the
     instance."

  3) Change the DESCRIPTION for "rohcProfile to:
     "Identifier of a profile supported. For a listing of
     possible profile values, see the IANA registry for ROHC
     profiles [PROFILES]."

  4) Add the following normative reference:
     [PROFILES]  "RObust Header Compression (ROHC) Profile 
                 Identifiers", IANA registry at:
                 <http://www.iana.org/assignments/rohc-pro-ids>

  5) Add the following to "RohcProfileEntry":
       rohcProfileNegotiated   TruthValue

  6) Add:
         rohcProfileNegotiated OBJECT-TYPE
             SYNTAX      TruthValue
             MAX-ACCESS  read-only
             STATUS      current
             DESCRIPTION
                 "When retrieved, this boolean object returns true
                  if the profile has been negotiated to be used at
                  the instance, i.e. is supported also be the
                  corresponding compressor/decompressor."
             ::= { rohcProfileEntry 7 }
                  
- On page 21, "rohcContextStorageTime", the indentation is
  wrong (at least 3 spaces more than elsewhere).

- On page 33, "rohcContextState", there is a (to me) unknown
  state listed, "normal(2)". I do not know where this comes
  from, but I am pretty sure it should not be there. Make it
  6 states by removing "normal". This affects both SYNTAX and
  DESCRIPTION.

- Section 6, end of 7th line, should say "rows", not "row".

- Section 8.1, please change the way my name is written in 
  the second and third references, should be written "L-E.",
  not "L.-E.". Thanks!


That's all!

Cheers,
/L-E




> -----Original Message-----
> From: cabo@tzi.org [mailto:cabo@tzi.org]
> Sent: den 15 januari 2003 17:21
> To: ROHC WG
> Subject: [rohc] WG last-call for ROHC MIB and related documents
> 
> 
> ROHCers,
> 
> In Atlanta, we said we were going to have another re-spin of the ROHC
> MIB to include LLA.  This has now been available for nearly a month,
> and we believe the document has received enough review to issue the WG
> last-call.  Together with this goes the terminology and examples
> document as additional explanatory material that at some point is
> expected to become part of the ROHC draft standard.
> 
> Therefore, we are now issuing a WG last-call for the following two
> documents:
> 
>   draft-ietf-rohc-mib-rtp-05.txt
>       (for publication as Proposed Standard)
> 
>   draft-ietf-rohc-terminology-and-examples-01.txt
>       (for publication as Informational)
> 
> This is a regular two-week WG last-call.
> 
> Please direct WG last-call comments to the ROHC mailing list
> rohc@ietf.org before Wed, 2003-01-29, 18:00 UTC.
> 
> Gruesse, Carsten
> 
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
> 
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Thu Jan 23 13:09:04 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15304
	for <rohc-archive@odin.ietf.org>; Thu, 23 Jan 2003 13:09:04 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0NIRfH13439
	for rohc-archive@odin.ietf.org; Thu, 23 Jan 2003 13:27:41 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NIRfJ13436
	for <rohc-web-archive@optimus.ietf.org>; Thu, 23 Jan 2003 13:27:41 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15289
	for <rohc-web-archive@ietf.org>; Thu, 23 Jan 2003 13:08:33 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NIRPJ13427;
	Thu, 23 Jan 2003 13:27:25 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NIQAJ13368
	for <rohc@optimus.ietf.org>; Thu, 23 Jan 2003 13:26:10 -0500
Received: from mail.cit.ie (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15272
	for <rohc@ietf.org>; Thu, 23 Jan 2003 13:07:01 -0500 (EST)
Received: from EEB174W2Kvk (unverified [157.190.81.172]) by cit.ie
 (Rockliffe SMTPRA 5.2.5) with SMTP id <B0000104046@mail.cit.ie> for <rohc@ietf.org>;
 Thu, 23 Jan 2003 18:00:28 +0000
Reply-To: <vkenneally@cit.ie>
From: "Valerie Kenneally" <vkenneally@cit.ie>
To: <rohc@ietf.org>
Date: Thu, 23 Jan 2003 18:10:47 -0000
Message-ID: <NIEFLFDIBJCPCKAMIGBPGENJCEAA.vkenneally@cit.ie>
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.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [rohc] SigComp and State
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi All,

	I am currently studying SigComp and am trying to understand each of the
different entities it entails.  RFC 3320 has the following explanation

"State Handler-the entity that can store and retrieve state. State is
information that is stored between SigComp messages, avoiding the need to
upload the data on a per-message basis."

I am trying to comprehend this idea of "State".  So I have the following
questions:

1.  Is state the uncompressed message details that are being sent on the
compressor side and the decompressed message on the receiving/decompressor
side?
2.  If this is the case and we create a state identifier on the compressor
side for the first message ever to be transmitted, is this state identifier
transmitted to the remote end-point along with the SigComp message, not for
decompression purposes in this case but in order to save state in the
decompressor side?

3.  If we send a Sigcomp message with a state identifier to be used for
decompression then are the state identifiers existent in the two
communicating endpoints mirror images of each other?  In other words do we
have mirror compartments at communicating entities?

Really hoping someone can clear up my understanding
Regards,
Val


-------------------Legal  Disclaimer---------------------------------------

The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt.

----------------------------------------------------------------------------------------

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



From mailnull@www1.ietf.org  Thu Jan 23 23:11:53 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29845
	for <rohc-archive@odin.ietf.org>; Thu, 23 Jan 2003 23:11:53 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0O4UhM19593
	for rohc-archive@odin.ietf.org; Thu, 23 Jan 2003 23:30:43 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O4UhJ19590
	for <rohc-web-archive@optimus.ietf.org>; Thu, 23 Jan 2003 23:30:43 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29839
	for <rohc-web-archive@ietf.org>; Thu, 23 Jan 2003 23:11:22 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O4UVJ19566;
	Thu, 23 Jan 2003 23:30:32 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O4TBJ19514
	for <rohc@optimus.ietf.org>; Thu, 23 Jan 2003 23:29:11 -0500
Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29807
	for <rohc@ietf.org>; Thu, 23 Jan 2003 23:09:49 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <CN3C09TL>; Fri, 24 Jan 2003 04:13:17 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED41805DF6631@rsys002a.roke.co.uk>
From: "West, Mark (ITN)" <mark.a.west@roke.co.uk>
To: Kuntal Chowdhury <kuntal@iqmail.net>, rohc@ietf.org
Subject: RE: [rohc] comment on ROHC-TCP
Date: Fri, 24 Jan 2003 04:13:07 -0000
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-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>


Hi Kuntal,

Thanks for this comment (which relates to the behaviour as well as to the interpretation of this in the main compression draft).  I've got a bunch of updates for the TCP behavior (thanks to a number of very useful comments from various people) -- and this has reminded me to post a proposed update!

Broadly speaking, I agree with your distinction.  However, it raises a couple of interesting points.  For example, it is perhaps worth pointing out that 'short-lived' doesn't necessarily relate to the duration for which the connection is open, but rather the volume of data that is transferred.  So, for example, the FTP control connection could be regarded as short-lived (at leat compared with the data connection)?!  (I don't know if that necessarily makes an isolated short-lived connection less rare, though...)

In principle, your comments about HTTP/1.0 vs HTTP/1.1 make sense.  But if I understand it correctly, the benefits of HTTP/1.1 rely upon agreement between the browser and server and the appropriate configuration of both (certainly of the server)?  You can certainly still have multiple connections to the server with HTTP/1.1.  I'd certainly appreciate input on this application-layer behaviour, as it impacts on the transport.

Anyway, I'll propose some updated (behaviour) text in the next few days.

Cheers,

Mark.



> -----Original Message-----
> From: Kuntal Chowdhury [mailto:kuntal@iqmail.net]
> Sent: 21 January 2003 20:38
> To: rohc@ietf.org
> Subject: [rohc] comment on ROHC-TCP
> 
> 
> Hello folks,
> I think we need to separate the issues between a single short 
> lived TCP 
> connection (rare event) from multiple (near-)simultaneous short lived
> TCP connections. The reason being, the scenario of single short lived 
> TCP connection applies to both HTTP1.0 and 1.1, however the 
> scenario of 
> multiple short lived (near-)simultaneous TCP connections may be a 
> problem with HTTP1.0 only (HTTP1.1 solves the problem with 
> persistence 
> and pipelining as default behavior). Therefore I suggest, we split 
> section 3.3 to discuss single short lived and multiple 
> (near-)simultaneous short lived TCP connections separately.
> 
> Thoughts?
> 
> -Kuntal
> 
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
> 
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Fri Jan 24 03:25:20 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12802
	for <rohc-archive@odin.ietf.org>; Fri, 24 Jan 2003 03:25:20 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0O8iFI11851
	for rohc-archive@odin.ietf.org; Fri, 24 Jan 2003 03:44:15 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O8iEJ11847
	for <rohc-web-archive@optimus.ietf.org>; Fri, 24 Jan 2003 03:44:14 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12796
	for <rohc-web-archive@ietf.org>; Fri, 24 Jan 2003 03:24:48 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O8hxJ11830;
	Fri, 24 Jan 2003 03:43:59 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O8g9J11765
	for <rohc@optimus.ietf.org>; Fri, 24 Jan 2003 03:42:09 -0500
Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12757
	for <rohc@ietf.org>; Fri, 24 Jan 2003 03:22:43 -0500 (EST)
Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0O8QAKX002866
	for <rohc@ietf.org>; Fri, 24 Jan 2003 09:26:11 +0100 (MET)
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <DLVCQJWT>; Fri, 24 Jan 2003 09:26:10 +0100
Message-ID: <A943FD84BD9ED41193460008C791805003E3250A@ESEALNT419.al.sw.ericsson.se>
From: "Lars-Erik Jonsson (EAB)" <Lars-Erik.Jonsson@epl.ericsson.se>
To: rohc@ietf.org
Subject: RE: [rohc] I-D ACTION:draft-ietf-rohc-ip-only-01.txt
Date: Fri, 24 Jan 2003 09:26:05 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Dear all,

The IP profile draft has been updated according to what was
outlined in Atlanta, and reflected in the minutes. This means:
- The termination has been defined
- Compression of headers with an arbitrary number of IP headers
  is now supported through the addition of a dynamic header
  chain list for "IP3+" in compressed headers.

As always, comments are appreciated!
/L-E


> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> Sent: den 23 januari 2003 13:47
> Cc: rohc@ietf.org
> Subject: [rohc] I-D ACTION:draft-ietf-rohc-ip-only-01.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the Robust Header Compression 
> Working Group of the IETF.
> 
> 	Title		: RObust Header Compression (ROHC): A 
> Compression 
>                           Profile for IP
> 	Author(s)	: L. Jonsson
> 	Filename	: draft-ietf-rohc-ip-only-01.txt
> 	Pages		: 8
> 	Date		: 2003-1-22
> 	
> The original RObust Header Compression (ROHC) RFC, RFC 3095, defines
> a framework for header compression, along with compression protocols
> (profiles) for IP/UDP/RTP, IP/ESP, IP/UDP, and also a profile for
> uncompressed packet streams. However, no profile was defined for
> compression of IP only, which has been identified as a missing piece
> in RFC 3095. This document defines a ROHC compression profile for IP,
> similar to the IP/UDP profile defined by RFC 3095, but simplified to
> exclude UDP, and enhanced to compress IP header chains of arbitrary
> length.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-rohc-ip-only-01.txt
> 
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body 
> of the message.
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-rohc-ip-only-01.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	mailserv@ietf.org.
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-rohc-ip-only-01.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Fri Jan 24 03:40:20 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13011
	for <rohc-archive@odin.ietf.org>; Fri, 24 Jan 2003 03:40:20 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0O8xF712515
	for rohc-archive@odin.ietf.org; Fri, 24 Jan 2003 03:59:15 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O8xFJ12512
	for <rohc-web-archive@optimus.ietf.org>; Fri, 24 Jan 2003 03:59:15 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12978
	for <rohc-web-archive@ietf.org>; Fri, 24 Jan 2003 03:39:49 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O8wBJ12457;
	Fri, 24 Jan 2003 03:58:11 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O8vwJ12401
	for <rohc@optimus.ietf.org>; Fri, 24 Jan 2003 03:57:58 -0500
Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12928
	for <rohc@ietf.org>; Fri, 24 Jan 2003 03:38:32 -0500 (EST)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0O8g0KV008265;
	Fri, 24 Jan 2003 09:42:00 +0100 (MET)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <DLW0GRWN>; Fri, 24 Jan 2003 09:42:00 +0100
Message-ID: <F005CD411D18D3119C8F00508B0874800A144688@ehubunt100.eth.ericsson.se>
From: "Lajos Zaccomer (ETH)" <Lajos.Zaccomer@eth.ericsson.se>
To: "'vkenneally@cit.ie'" <vkenneally@cit.ie>, rohc@ietf.org
Subject: RE: [rohc] SigComp and State
Date: Fri, 24 Jan 2003 09:40:00 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi Val,

I'm trying to answer your question the best I can.

1.  Is state the uncompressed message details that are being sent on the
compressor side and the decompressed message on the receiving/decompressor
side?

A state may contain anything you want. In most cases, states are simply decompressed messages or just a part of them. But one can store other information in a state, for example a number identifying a message, or state length as it can not be retrieved with the STATE-ACCESS instruction. Only imagination limits what you can put into a state.

2.  If this is the case and we create a state identifier on the compressor
side for the first message ever to be transmitted, is this state identifier
transmitted to the remote end-point along with the SigComp message, not for
decompression purposes in this case but in order to save state in the
decompressor side?

The state id should not be sent in the message. The STATE-CREATE instruction produces a state id for the state to be saved.

3.  If we send a Sigcomp message with a state identifier to be used for
decompression then are the state identifiers existent in the two
communicating endpoints mirror images of each other?  In other words do we
have mirror compartments at communicating entities?

Not necessarily. If a state id is used to access a state, the state memory should be handled in a way that the sate can be accessed. But it does not mean we have mirror compartments. Think of dropped messages and shared states e.g!


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



From mailnull@www1.ietf.org  Fri Jan 24 04:06:44 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13682
	for <rohc-archive@odin.ietf.org>; Fri, 24 Jan 2003 04:06:43 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0O9PdB14718
	for rohc-archive@odin.ietf.org; Fri, 24 Jan 2003 04:25:39 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O9PcJ14715
	for <rohc-web-archive@optimus.ietf.org>; Fri, 24 Jan 2003 04:25:38 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13660
	for <rohc-web-archive@ietf.org>; Fri, 24 Jan 2003 04:06:12 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O9PFJ14677;
	Fri, 24 Jan 2003 04:25:15 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O9MMJ14554
	for <rohc@optimus.ietf.org>; Fri, 24 Jan 2003 04:22:22 -0500
Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13543
	for <rohc@ietf.org>; Fri, 24 Jan 2003 04:02:53 -0500 (EST)
Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0O96JAw024224
	for <rohc@ietf.org>; Fri, 24 Jan 2003 10:06:20 +0100 (MET)
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <DLVCQW7R>; Fri, 24 Jan 2003 10:06:19 +0100
Message-ID: <A943FD84BD9ED41193460008C791805003E3250C@ESEALNT419.al.sw.ericsson.se>
From: "Lars-Erik Jonsson (EAB)" <Lars-Erik.Jonsson@epl.ericsson.se>
To: ROHC WG <rohc@ietf.org>
Subject: RE: [rohc] WG last-call for ROHC MIB and related documents
Date: Fri, 24 Jan 2003 10:06:14 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

I have once again reviewed the "Terminology and Examples"
document, which I am also the author of, and found the following
that should be corrected:

- Section 3.2, last sentence, should end "...channel concept is used,
  as defined above."

- Section 4.2, "Feedback Output", second line, should be: "...is
  sent from the decompressor through..." instead of "...is sent by
  the compressor through...", for correctness and consistency.

- Section 5, third paragraph, last sentence, "ROHC peers" is not
  defined in terminology, and not used clearly in the document,
  should be made consistent.

- Section 6.2, first sentence should read "This section...", instead
  of "This chapter...".

- Section 6.3, first sentence should read "This section...", instead
  of "This chapter...".

- Section 6.3, figure, lower left decompressor, upper left output
  should be labeled "DO", not "FO".

- Section 6.3, description of figure is not correct, on the upper
  two instances, the FI/PI and PO/FO connections have been switched,
  respectively, while the lower two instances have been horizontally
  mirrored. Last sentence of the last paragraph should thus be 
  rewritten to correctly reflect this.

- Section 9, last sentence of second paragraph, should say
  "...those in one separate ROHC framework module, and...", instead
  of "...those separately, and... 


/L-E



> -----Original Message-----
> From: cabo@tzi.org [mailto:cabo@tzi.org]
> Sent: den 15 januari 2003 17:21
> To: ROHC WG
> Subject: [rohc] WG last-call for ROHC MIB and related documents
> 
> 
> ROHCers,
> 
> In Atlanta, we said we were going to have another re-spin of the ROHC
> MIB to include LLA.  This has now been available for nearly a month,
> and we believe the document has received enough review to issue the WG
> last-call.  Together with this goes the terminology and examples
> document as additional explanatory material that at some point is
> expected to become part of the ROHC draft standard.
> 
> Therefore, we are now issuing a WG last-call for the following two
> documents:
> 
>   draft-ietf-rohc-mib-rtp-05.txt
>       (for publication as Proposed Standard)
> 
>   draft-ietf-rohc-terminology-and-examples-01.txt
>       (for publication as Informational)
> 
> This is a regular two-week WG last-call.
> 
> Please direct WG last-call comments to the ROHC mailing list
> rohc@ietf.org before Wed, 2003-01-29, 18:00 UTC.
> 
> Gruesse, Carsten
> 
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
> 
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Fri Jan 24 04:53:27 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14492
	for <rohc-archive@odin.ietf.org>; Fri, 24 Jan 2003 04:53:27 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0OACOE18204
	for rohc-archive@odin.ietf.org; Fri, 24 Jan 2003 05:12:24 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OACOJ18200
	for <rohc-web-archive@optimus.ietf.org>; Fri, 24 Jan 2003 05:12:24 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14479
	for <rohc-web-archive@ietf.org>; Fri, 24 Jan 2003 04:52:56 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OACDJ18187;
	Fri, 24 Jan 2003 05:12:13 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OABbJ18135
	for <rohc@optimus.ietf.org>; Fri, 24 Jan 2003 05:11:37 -0500
Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14473
	for <rohc@ietf.org>; Fri, 24 Jan 2003 04:52:09 -0500 (EST)
Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0O9tZKY004622
	for <rohc@ietf.org>; Fri, 24 Jan 2003 10:55:37 +0100 (MET)
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <DLVCRGT6>; Fri, 24 Jan 2003 10:55:17 +0100
Message-ID: <A943FD84BD9ED41193460008C791805005651100@ESEALNT419.al.sw.ericsson.se>
From: "Hans Hannu (EAB)" <Hans.Hannu@epl.ericsson.se>
To: ROHC WG <rohc@ietf.org>
Subject: RE: [rohc] WG last-call for ROHC MIB and related documents
Date: Fri, 24 Jan 2003 10:55:08 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi,

I've reviewed the "Terminology and Examples" document and have the 
following comments:

- Section 2, page 4, paragraph "Co-located compressor/decompressor".  
What is the meaning with "pair" in paragraph "Co-located compressor/decompressor"? 
Is it the co-located compressor and decompressor that makes up the "pair", or does 
the "pair" correspond to the co-located compressor and decompressor at one end 
together with the co-located compressor and decompressor at the other end of the link?  

- Section 2, page 4, paragraph "Associated compressor/decompressor".
Remove second word of ROHC at line 5 (easier to couple the instances together), 
and make singular of ROHC compressor/ at line 7.
* Old
      "sent from the co-located ROHC compressor to the ROHC decompressor
      co-located with the compressor at the other end. When a co-located
      ROHC compressors/decompressor pair is connected for this purpose,
      they are said to be associated with each other."
* New
      "sent from the co-located ROHC compressor to the decompressor
      co-located with the compressor at the other end. When a co-located
      ROHC compressor/decompressor pair is connected for this purpose,
      they are said to be associated with each other."

- Section 2, page 5, paragraphs "Interspersed feedback" and 
"Piggybacked feedback".
The word "channel" is used at line 5 of both paragraphs, could perhaps be
changed to "ROHC channel"

- Section 3.2, page 7, last paragraph.
Consider changing
* Old 
     "channel definition is slightly enhanced for header compression by the
     definition of ROHC channels (section 5) and ROHC feedback channels"

* New 
     "channel definition is slightly enhanced for header compression by the
     definition of the ROHC channel (section 5) and the ROHC feedback channel"     

- Section 4.1, page 11, last paragraph.
The word "channel" is used at line 4, could perhaps be
changed to "ROHC channel"

- Section 5, page 13, third paragraph.
Perhaps one could define, "ROHC peers" in the terminology section.

BR
/Hans H


> -----Original Message-----
> From: cabo@tzi.org [mailto:cabo@tzi.org]
> Sent: den 15 januari 2003 17:21
> To: ROHC WG
> Subject: [rohc] WG last-call for ROHC MIB and related documents
> 
> 
> ROHCers,
> 
> In Atlanta, we said we were going to have another re-spin of the ROHC
> MIB to include LLA.  This has now been available for nearly a month,
> and we believe the document has received enough review to issue the WG
> last-call.  Together with this goes the terminology and examples
> document as additional explanatory material that at some point is
> expected to become part of the ROHC draft standard.
> 
> Therefore, we are now issuing a WG last-call for the following two
> documents:
> 
>   draft-ietf-rohc-mib-rtp-05.txt
>       (for publication as Proposed Standard)
> 
>   draft-ietf-rohc-terminology-and-examples-01.txt
>       (for publication as Informational)
> 
> This is a regular two-week WG last-call.
> 
> Please direct WG last-call comments to the ROHC mailing list
> rohc@ietf.org before Wed, 2003-01-29, 18:00 UTC.
> 
> Gruesse, Carsten
> 
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
> 
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Fri Jan 24 05:11:24 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14817
	for <rohc-archive@odin.ietf.org>; Fri, 24 Jan 2003 05:11:24 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0OAUM019082
	for rohc-archive@odin.ietf.org; Fri, 24 Jan 2003 05:30:22 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OAULJ19079
	for <rohc-web-archive@optimus.ietf.org>; Fri, 24 Jan 2003 05:30:21 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14786
	for <rohc-web-archive@ietf.org>; Fri, 24 Jan 2003 05:10:53 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OAU7J19035;
	Fri, 24 Jan 2003 05:30:07 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OAT3J18980
	for <rohc@optimus.ietf.org>; Fri, 24 Jan 2003 05:29:03 -0500
Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14750;
	Fri, 24 Jan 2003 05:09:34 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <CN3C00BN>; Fri, 24 Jan 2003 10:13:01 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F195@rsys002a.roke.co.uk>
From: "Price, Richard" <richard.price@roke.co.uk>
To: "'Lars-Erik Jonsson (EAB)'" <Lars-Erik.Jonsson@epl.ericsson.se>,
        "'rohc@ietf.org'" <rohc@ietf.org>
Cc: "'sigtran@ietf.org'" <sigtran@ietf.org>,
        "'tsvwg@ietf.org'"
	 <tsvwg@ietf.org>,
        "Allison Mankin (E-mail)" <mankin@psg.com>
Subject: RE: [rohc] Removing SCTP header compression from the ROHC charter
Date: Fri, 24 Jan 2003 10:13:01 -0000
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-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

> Trying to fulfill this work item during the last year, we have
> repeatedly asked for contributions to SCTP header compression, but
> we have not received a single response.

We published a first version of an SCTP compression profile in
draft-west-sctp-epic-00.txt. This draft is based on the formal header
compression notation (see draft-ietf-rohc-formal-notation-00.txt),
so we intend to update the SCTP draft once the formal notation draft
is finalised.

> Given that this work item was originally added without immediate
> market pull, and considering the lack of current interest in doing
> the work (or even having it done at all), we intend to remove SCTP
> header compression from the ROHC WG charter.  To keep it in the
> charter, justifications for developing SCTP header compression now
> would have to be presented, as well as industry support and
> commitments for doing the actual work.

This work item is important because, unlike for TCP, there is currently
no published scheme for SCTP compression. This will hinder the
deployment of SCTP, particularly in the mobile environment.

Regarding the industry support, we're currently working on SCTP
compression at the moment in the form of the notation draft. Once this
work is done we'll publish an updated version of our SCTP profile.

> Barring further input, we will send a request to the ADs by Jan 24,
> so please reply before this date if you believe SCTP header
> compression should be on the agenda now.

I believe that SCTP compression should remain on the ROHC charter.

Regards,

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



From mailnull@www1.ietf.org  Fri Jan 24 20:02:24 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06683
	for <rohc-archive@odin.ietf.org>; Fri, 24 Jan 2003 20:02:24 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0P1LcH10452
	for rohc-archive@odin.ietf.org; Fri, 24 Jan 2003 20:21:38 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P1LcJ10449
	for <rohc-web-archive@optimus.ietf.org>; Fri, 24 Jan 2003 20:21:38 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06671
	for <rohc-web-archive@ietf.org>; Fri, 24 Jan 2003 20:01:53 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P1LPJ10433;
	Fri, 24 Jan 2003 20:21:25 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P1K6J10406
	for <rohc@optimus.ietf.org>; Fri, 24 Jan 2003 20:20:06 -0500
Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06649
	for <rohc@ietf.org>; Fri, 24 Jan 2003 20:00:20 -0500 (EST)
From: zhigang.c.liu@nokia.com
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0P12k024102
	for <rohc@ietf.org>; Sat, 25 Jan 2003 03:02:46 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5fffb32451ac158f21081@esvir01nok.ntc.nokia.com> for <rohc@ietf.org>;
 Sat, 25 Jan 2003 03:03:43 +0200
Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Sat, 25 Jan 2003 03:03:45 +0200
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Fri, 24 Jan 2003 19:03:41 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_001_01C2C40D.995426FD"
Date: Fri, 24 Jan 2003 19:03:40 -0600
Message-ID: <DE0842B293FC4847992F9EDF8D72E1ED0133DF6B@daebe005.americas.nokia.com>
X-MS-Has-Attach: yes
Thread-Topic: a dummy application protocol (DAP) for SigComp interop
Thread-Index: AcLEDYg4cNZd4y9+EdeaNgAQpIbXLw==
To: <rohc@ietf.org>
X-OriginalArrivalTime: 25 Jan 2003 01:03:41.0303 (UTC) FILETIME=[99C1D070:01C2C40D]
Subject: [rohc] a dummy application protocol (DAP) for SigComp interop
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C2C40D.995426FD
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

Attached is a simple protocol that can be used for the=20
interop test during SIPit in February.=20

Your comments are welcome.

Zhigang

------_=_NextPart_001_01C2C40D.995426FD
Content-Type: text/plain;
	name="dap-1.txt"
Content-Description: dap-1.txt
Content-Disposition: attachment;
	filename="dap-1.txt"
Content-Transfer-Encoding: base64

QSBEdW1teSBBcHBsaWNhdGlvbiBQcm90b2NvbCAoREFQKQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLQ0KDQoxLiBJbnRyb2R1Y3Rpb24NCg0KVGhpcyBkb2N1bWVudCBkZWZpbmVz
IGEgc2ltcGxlIGR1bW15IGFwcGxpY2F0aW9uIHByb3RvY29sIChEQVApDQp0aGF0IGNhbiBiZSB1
c2VkIGZvciBTaWdDb21wIGludGVyb3BlcmFiaWxpdHkgdGVzdC4gVGhpcyBpcyBoYW5keQ0KZm9y
IFNpZ0NvbXAgaW1wbGVtZW50YXRpb25zIHRoYXQgYXJlIG5vdCBpbnRlZ3JhdGVkIHdpdGggU0lQ
IHN0YWNrLg0KSXQgYWxzbyBwcm92aWRlcyBzb21lIGZlYXR1cmVzIHRoYXQgZmFjaWxpdGF0ZSB0
aGUgdGVzdHMgb2YgU2lnQ29tcA0KaW50ZXJuYWwgb3BlcmF0aW9ucy4NCg0KVGhlIG1lc3NhZ2Ug
Zm9ybWF0IGlzIHF1aXRlIHNpbXBsZS4gRWFjaCBtZXNzYWdlIGNvbnNpc3RzIG9mIGEgNy1saW5l
DQptZXNzYWdlLWhlYWRlciwgYW4gZW1wdHkgbGluZSwgYW5kIGFuIG9wdGlvbmFsIG1lc3NhZ2Ut
Ym9keS4gWW91IA0KY2FuIHNlZSB0aGUgc3R5bGUgcmVzZW1ibGVzIHRoYXQgb2YgU0lQIGFuZCBI
VFRQLg0KDQpUaGUgZXhhY3QgbWVzc2FnZSBmb3JtYXQgaXMgZ2l2ZW4gbGF0ZXIgaW4gYXVnbWVu
dGVkIEJhY2t1cy1OYXVyIEZvcm0gDQooQUJORikgKHNlZSBSRkMgMjIzNCkuIEhlcmUgYXJlIGEg
ZmV3IG5vdGVzOg0KDQotIEVhY2ggbGluZSBvZiBtZXNzYWdlLWhlYWRlciBtdXN0IGJlIHRlcm1p
bmF0ZWQgd2l0aCBDUiBMRi4NCi0gVGhlIGVtcHR5IGxpbmUgbXVzdCBiZSBwcmVzZW50IGV2ZW4g
aWYgdGhlIG1lc3NhZ2UtYm9keSBpcyBub3QuDQotIEJvZHktbGVuZ3RoIGlzIHRoZSBsZW5ndGgg
b2YgdGhlIG1lc3NhZ2UtYm9keSwgZXhjbHVkaW5nIHRoZQ0KQ1JMRiB3aGljaCBzZXBhcmF0ZXMg
dGhlIG1lc3NhZ2UtYm9keSBmcm9tIHRoZSBtZXNzYWdlLWhlYWRlci4NCi0gQWxsIHN0cmluZ3Mg
aW4gbWVzc2FnZS1oZWFkZXIgYXJlIGNhc2UtaW5zZW5zaXRpdmUuDQotIEZvciBub3csIHRoZSBE
QVAtdmVyc2lvbiBtdXN0IGJlIHNldCB0byAxLiANCg0KDQpQcm9jZXNzaW5nIGEgREFQIG1lc3Nh
Z2U6DQoNCi0gQSBtZXNzYWdlIHdpdGggaW52YWxpZCBmb3JtYXQgd2lsbCBiZSBkaXNjYXJkZWQg
YnkgYSBEQVAgcmVjZWl2ZXINCg0KLSBGb3IgdGVzdGluZyBwdXJwb3NlLCBhIG1lc3NhZ2Ugd2l0
aCB2YWxpZCBmb3JtYXQgd2lsbCBiZSByZXR1cm5lZCANCnRvIHRoZSBvcmlnaW5hbCBzZW5kZXIg
KElQIGFkZHJlc3MsIHBvcnQgbnVtYmVyKSBpbiBjbGVhciB0ZXh0LCBpLmUuLCANCndpdGhvdXQg
Y29tcHJlc3Npb24uIFRoaXMgaXMgdGhlIGNhc2UgZXZlbiBpZiB0aGUgc2VuZGVyIHJlcXVlc3Rz
DQp0aGUgcmVjZWl2ZXIgdG8gcmVqZWN0IHRoaXMgbWVzc2FnZS4NCg0KLSBHbG9iYWwtSUQgaXMg
dGhlIGlkZW50aWZpZXIgb2YgYSBTaWdDb21wIGVuZHBvaW50LiBJdCBpcyBuZWVkZWQgdG8NCnRl
c3QgdGhlIGNhc2Ugd2hlcmUgbXVsdGlwbGUgU2lnQ29tcCBlbmRwb2ludHMgY29tbXVuaWNhdGUg
d2l0aCBvbmUgDQpyZW1vdGUgU2lnQ29tcCBlbmRwb2ludC4gRm9yIHNpbXBsaWNpdHksIElQdjQg
YWRkcmVzcyBpcyB1c2VkIGZvciB0aGlzIA0KcHVycG9zZS4gW2F1dGhvcidzIG5vdGU6IGRvIHdl
IG5lZWQgdG8gaW5jbHVkZSBJUHY2IGFkZHJlc3M/XQ0KDQotIEEgREFQIHJlY2VpdmVyIHNob3Vs
ZCBmb2xsb3cgdGhlIGluc3RydWN0aW9uIGNhcnJpZWQgaW4gaGVhZGVyIGxpbmUtNQ0KdG8gZWl0
aGVyIGFjY2VwdCBvciByZWplY3QgYSBtZXNzYWdlLiBTaW1pbGFybHksIGl0IHNob3VsZCBmb2xs
b3cgdGhlDQppbnN0cnVjdGlvbiBpbiBsaW5lLTYgdG8gY3JlYXRlIG9yIGNsb3NlIGEgY29tcGFy
dG1lbnQuIE5vdGUgaG93ZXZlciwNCmhlYWRlciBsaW5lLTYgd2lsbCBiZSBpZ25vcmVkIGlmIGhl
YWRlciBsaW5lLTUgc2F5cyB0aGUgbWVzc2FnZSBzaG91bGQgDQpiZSByZWplY3RlZC4NCg0KLSBN
ZXNzYWdlLXNlcSBjYW4gYmUgdXNlZCBieSBhIERBUCBzZW5kZXIgdG8gdHJhY2sgZWFjaCBtZXNz
YWdlIGl0IHNlbmRzLA0KZS5nLiwgaW4gY2FzZSBvZiBsb3NzZXMuIE5vdGUgdGhhdCBhIG1lc3Nh
Z2UgY291bGQgYmUgbG9zdCBlaXRoZXIgb24gdGhlDQpwYXRoIG9yIGF0IHRoZSBTaWdDb21wIHJl
Y2VpdmVyIChkdWUgdG8gZGVjb21wcmVzc2lvbiBmYWlsdXJlKS4NCg0KDQoNCjIuIERBUCBtZXNz
YWdlIGZvcm1hdCBpbiBBQk5GDQoNCihOb3RlOiBzZWUgUkZDIDIyMzQgZm9yIGJhc2ljIHJ1bGVz
LikNCg0KREFQLW1lc3NhZ2UgPSBtZXNzYWdlLWhlYWRlcg0KICAgICAgICAgICAgICBDUkxGDQog
ICAgICAgICAgICAgIFsgbWVzc2FnZS1ib2R5IF0NCg0KbWVzc2FnZS1ib2R5ID0gKk9DVEVUDQoN
Cm1lc3NhZ2UtaGVhZGVyID0gbGluZS0xIGxpbmUtMiBsaW5lLTMgbGluZS00IGxpbmUtNSBsaW5l
LTYgbGluZS03DQoNCmxpbmUtMSA9ICJEQVAtdmVyc2lvbiIgIjoiIDEqRElHSVQgQ1JMRg0KbGlu
ZS0yID0gImdsb2JhbC1JRCIgIjoiIElQdjRhZGRyZXNzIENSTEYNCmxpbmUtMyA9ICJjb21wYXJ0
bWVudC1JRCIgIjoiIDEqRElHSVQgQ1JMRg0KbGluZS00ID0gIm1lc3NhZ2Utc2VxIiAiOiIgMSpE
SUdJVCBDUkxGDQpsaW5lLTUgPSAibWVzc2FnZS1hdXRoIiAiOiIgKCAiQUNDRVBUIiAvICJSRUpF
Q1QiICkgQ1JMRg0KbGluZS02ID0gImNvbXBhcnRtZW50LW9wIiAiOiIgKCAiQ1JFQVRFIiAvICJD
TE9TRSIgLyAiTk9ORSIgKSBDUkxGDQpsaW5lLTcgPSAiYm9keS1sZW5ndGgiICI6IiAxKkRJR0lU
IENSTEYNCg0KSVB2NGFkZHJlc3MgPSAxKjNESUdJVCAiLiIgMSozRElHSVQgIi4iIDEqM0RJR0lU
ICIuIiAxKjNESUdJVA0KDQoNCjMuIEFuIGV4YW1wbGUgb2YgYSBEQVAgbWVzc2FnZQ0KDQpEQVAt
dmVyc2lvbjogMQ0KZ2xvYmFsLUlEOiAxMjMuNDUuNjcuODkNCmNvbXBhcnRtZW50LUlEOiAyDQpt
ZXNzYWdlLXNlcTogMA0KbWVzc2FnZS1hdXRoOiBBQ0NFUFQNCmNvbXBhcnRtZW50LW9wOiBDUkVB
VEUNCmJvZHktbGVuZ3RoOiAxOTkNCg0KVGhpcyBpcyBhIERBUCBtZXNzYWdlIHNlbnQgZnJvbSBT
aWdDb21wIGVuZHBvaW50IGF0IElQIGFkZHJlc3MNCjEyMy40NS42Ny44OS4gVGhpcyBpcyB0aGUg
Zmlyc3QgbWVzc2FnZSBmb3IgdGhpcyBTaWdDb21wIGNvbXBhcnRtZW50DQooSUQgPSAyKS4gUGxl
YXNlIGFjY2VwdCB0aGUgbWVzc2FnZSBhbmQgY3JlYXRlIHRoZSBjb21wYXJ0bWVudC4NCg==

------_=_NextPart_001_01C2C40D.995426FD--
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Sun Jan 26 09:59:00 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18646
	for <rohc-archive@odin.ietf.org>; Sun, 26 Jan 2003 09:59:00 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0QFJ0W07715
	for rohc-archive@odin.ietf.org; Sun, 26 Jan 2003 10:19:00 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0QFJ0J07708
	for <rohc-web-archive@optimus.ietf.org>; Sun, 26 Jan 2003 10:19:00 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18637
	for <rohc-web-archive@ietf.org>; Sun, 26 Jan 2003 09:58:28 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0QFIiJ07698;
	Sun, 26 Jan 2003 10:18:45 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0QFFfJ07639
	for <rohc@optimus.ietf.org>; Sun, 26 Jan 2003 10:15:41 -0500
Received: from maxwell2.pacific.net.sg (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18594
	for <rohc@ietf.org>; Sun, 26 Jan 2003 09:55:06 -0500 (EST)
Received: from oemcomputer ([210.24.107.21]) by maxwell2.pacific.net.sg
          with SMTP
          id <20030126145833.QQEJ13425.maxwell2.pacific.net.sg@oemcomputer>
          for <rohc@ietf.org>; Sun, 26 Jan 2003 22:58:33 +0800
X-Sender: chankm@gwserver.icr.a-star.edu.sg
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Sun, 26 Jan 2003 23:00:02 +0800
To: "'rohc@ietf.org'" <rohc@ietf.org>
From: Chan Kwang Mien <chankm@icr.a-star.edu.sg>
In-Reply-To: <76C92FBBFB58D411AE760090271ED41804A0F195@rsys002a.roke.co.
 uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <20030126145833.QQEJ13425.maxwell2.pacific.net.sg@oemcomputer>
Subject: [rohc] Multiple Compartment Test in SigComp Torture Tests
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

hi,

i would like to ask about the 4.3 Multiple Compartments test in the SigComp
Torture Test.

when the compressed message is 0x00, the memory location, type initially
contains the value 512
and state is created over the memory location from 512 to 959 because of 
STATE-CREATE(448, $type, 0, 6, 0). 

my problem is that the state identifier that i obtained for this
State-Create is not any of the state identifiers indicated 
in the assembly code. the state identifier that i generated for 2.15 State
Creation test is the same as the one in the 
assembly code. 

i would like to know if it is possible to obtain the same state identifier
when it is part of the memory 
over which the state identifier is to be calculated ? for e.g. is it
possible to obtain state_identifier_a when 
state_identifier_a is part of the memory over which the state identifier is
to be generated ?

Any help is much appreciated. Thanks.

regards,
Kwang Mien


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



From mailnull@www1.ietf.org  Mon Jan 27 05:04:15 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11219
	for <rohc-archive@odin.ietf.org>; Mon, 27 Jan 2003 05:04:15 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0RAOdj09713
	for rohc-archive@odin.ietf.org; Mon, 27 Jan 2003 05:24:39 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RAOdJ09710
	for <rohc-web-archive@optimus.ietf.org>; Mon, 27 Jan 2003 05:24:39 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11212
	for <rohc-web-archive@ietf.org>; Mon, 27 Jan 2003 05:03:44 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RAOIJ09695;
	Mon, 27 Jan 2003 05:24:18 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RALnJ09546
	for <rohc@optimus.ietf.org>; Mon, 27 Jan 2003 05:21:49 -0500
Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11134
	for <rohc@ietf.org>; Mon, 27 Jan 2003 05:00:53 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <CN3DABLV>; Mon, 27 Jan 2003 10:04:22 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F199@rsys002a.roke.co.uk>
From: "Price, Richard" <richard.price@roke.co.uk>
To: "'Chan Kwang Mien'" <chankm@icr.a-star.edu.sg>,
        "'rohc@ietf.org'"
	 <rohc@ietf.org>
Subject: RE: [rohc] Multiple Compartment Test in SigComp Torture Tests
Date: Mon, 27 Jan 2003 10:04:20 -0000
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-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

> i would like to ask about the 4.3 Multiple Compartments test 
> in the SigComp Torture Test.
> 
> when the compressed message is 0x00, the memory location, 
> type initially contains the value 512 and state is created over
> the memory location from 512 to 959 because of 
> STATE-CREATE(448, $type, 0, 6, 0). 

Hi Kwang Mien,

I think the problem is that STATE-CREATE uses byte copying to get
the state from the UDVM memory. Since byte_copy_left = 512 and
byte_copy_right = 519, all of the bytes in the state are copied
from the memory locations 512 up to 518 inclusive. Once address
518 is reached, the next byte must be copied from address 512.

> my problem is that the state identifier that i obtained for this
> State-Create is not any of the state identifiers indicated 
> in the assembly code. the state identifier that i generated 
> for 2.15 State Creation test is the same as the one in the 
> assembly code. 
> 
> i would like to know if it is possible to obtain the same 
> state identifier when it is part of the memory over which the
> state identifier is to be calculated ? for e.g. is it
> possible to obtain state_identifier_a when state_identifier_a
> is part of the memory over which the state identifier is
> to be generated ?

The above would be extremely unlikely to occur since the state
identifier is a hash of the memory over which it is calculated.
However, since STATE-CREATE obeys the byte copying rules it
shouldn't get any data from memory locations 519 or above (which
is where state_identifier_a is held). So the above situation
doesn't occur in the torture test.

Hope this helps!

Regards,

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



From mailnull@www1.ietf.org  Mon Jan 27 06:32:02 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12256
	for <rohc-archive@odin.ietf.org>; Mon, 27 Jan 2003 06:32:02 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0RBqSq14754
	for rohc-archive@odin.ietf.org; Mon, 27 Jan 2003 06:52:28 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RBqSJ14751
	for <rohc-web-archive@optimus.ietf.org>; Mon, 27 Jan 2003 06:52:28 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12248
	for <rohc-web-archive@ietf.org>; Mon, 27 Jan 2003 06:31:31 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RBqFJ14739;
	Mon, 27 Jan 2003 06:52:15 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RBnIJ14594
	for <rohc@optimus.ietf.org>; Mon, 27 Jan 2003 06:49:18 -0500
Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12190
	for <rohc@ietf.org>; Mon, 27 Jan 2003 06:28:21 -0500 (EST)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0RBVoAv017088;
	Mon, 27 Jan 2003 12:31:50 +0100 (MET)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <DW96CG4D>; Mon, 27 Jan 2003 12:31:50 +0100
Message-ID: <F005CD411D18D3119C8F00508B0874800A144697@ehubunt100.eth.ericsson.se>
From: "Lajos Zaccomer (ETH)" <Lajos.Zaccomer@eth.ericsson.se>
To: "'zhigang.c.liu@nokia.com'" <zhigang.c.liu@nokia.com>, rohc@ietf.org
Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp interop
Date: Mon, 27 Jan 2003 12:30:06 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi,

How will we test feedback, returned parameters and extended features with DAP? It seems that the receiving node is indeed a receiver and cannot be instructed to send me anything.

Zacco

-----Original Message-----
From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com]
Sent: Saturday, January 25, 2003 2:04 AM
To: rohc@ietf.org
Subject: [rohc] a dummy application protocol (DAP) for SigComp interop


Hi,

Attached is a simple protocol that can be used for the 
interop test during SIPit in February. 

Your comments are welcome.

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



From mailnull@www1.ietf.org  Mon Jan 27 12:31:27 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20315
	for <rohc-archive@odin.ietf.org>; Mon, 27 Jan 2003 12:31:27 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0RHq1W04573
	for rohc-archive@odin.ietf.org; Mon, 27 Jan 2003 12:52:01 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RHq0J04569
	for <rohc-web-archive@optimus.ietf.org>; Mon, 27 Jan 2003 12:52:00 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20294
	for <rohc-web-archive@ietf.org>; Mon, 27 Jan 2003 12:30:55 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RHpdJ04541;
	Mon, 27 Jan 2003 12:51:40 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RHopJ04483
	for <rohc@optimus.ietf.org>; Mon, 27 Jan 2003 12:50:51 -0500
Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20279
	for <rohc@ietf.org>; Mon, 27 Jan 2003 12:29:46 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <CN3DAC3A>; Mon, 27 Jan 2003 17:33:15 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F19C@rsys002a.roke.co.uk>
From: "Price, Richard" <richard.price@roke.co.uk>
To: "'rohc@ietf.org'" <rohc@ietf.org>
Date: Mon, 27 Jan 2003 17:33:11 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C2C62A.2A14A0DA"
Subject: [rohc] SigComp Interop
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C2C62A.2A14A0DA
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,

Attached is a first attempt at a test suite for the SigComp Interop.
Comments welcome!

Regards,

Richard

P.S. I also have a few answers to some issues raised in the original
proposal from Zacco:

> 1.2. Check if compressor and decompressor uses the same or separate
> state memory. (not specified in standard)

This should be covered by the following text from Section 6.2 of SigComp:

   Note that locally available state items (as described in Section
   3.3.3) need not be mapped to any particular compartment.  However, if
   they are created on a per-compartment basis, then they must not
   interfere with the state created at the request of the remote
   endpoint.  The special state_retention_priority of 65535 is reserved
   for locally available state items to ensure that this is the case.

So a compressor can create its own state in the state memory reserved for
the decompressor, but it must use the special state_retention_priority
of 65535. This makes sure that if the state memory runs out then the
state created by the compressor is discarded first (otherwise messages
might not decompress correctly).

> 2.1. Using shared state
> Calculation of shared state ID (not exactly specified in the
> draft, what to test?)

The contents of the shared state (and consequently the shared state ID)
should be exactly specified by RFC 3321. What the interop should test is
that Endpoint 1 can save a shared state and announce the corresponding
state ID to Endpoint 2, which then makes use of the state to improve the
overall compression ratio. The exact message format used to achieve this
is an implementation decision, but if any implementations can test the
example format given in RFC 3321 then that would be a bonus.

> 2.3. Using local endpoint initiated explicit acknowledgement
> What state ID is handled as an acked_state_id? (not specified in draft)

The acked_state_id can carry the ID of any state previously created by
the decompressor (in other words it's an alternative to using the
requested and returned SigComp feedback to acknowledge states).


------_=_NextPart_000_01C2C62A.2A14A0DA
Content-Type: text/plain;
	name="test_suite.txt"
Content-Disposition: attachment;
	filename="test_suite.txt"
Content-Transfer-Encoding: quoted-printable

Test Suite for the SigComp Interop:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

General notes:

Tests 5.1) and beyond apply SigComp to a complete application flow =
between two endpoints (denoted Endpoint 1 and Endpoint 2). In general =
these tests can be
run using an arbitrary application - the default will be the Dummy =
Application Protocol (DAP). The default transport layer is assumed to =
be UDP.

A comprehensive message flow for each test should include the =
following:

i) Realistic SIP data (this is useful for checking that mechanisms such =
as the static and user-specific dictionaries improve the overall =
compression ratio)
ii) "Null" messages containing just the basic header
iii) Long messages (up to 64K over UDP)
iv) Messages containing random data
v) Messages containing highly compressible data

Note that realistic SIP data can be encapsulated within DAP for the =
benefit of endpoints that don't understand native SIP.

It should also be possible to simulate the effects of dropping or =
misordering messages between the two SigComp endpoints.

Getting started:
----------------

1.1) Exchanging an uncompressed message flow

   The first test should exchange a cleartext (uncompressed) =
application message flow, to make sure that the two endpoints can talk =
to one another.

Basic SigComp (RFC 3320):
-------------------------

The following tests should cover the entities involved in receiving a =
SigComp message:

2.1) - 2.16) from the torture tests cover the UDVM.

3.1) - 3.3) from the torture tests cover the dispatcher.

4.1) - 4.3) from the torture tests cover the state handler.

It would be great if implementers could run these tests before the =
interop, to maximize the amount of time available for the "interactive" =
tests that
require support at both endpoints.

Note that implementers should run some or all of the tests using the =
"raw bytecode" given in the Appendix of the torture tests draft. This =
ensures that a
bug in the UDVM isn't cancelled out by an equivalent bug in the =
assembler.

SigComp-Extended (RFC 3321) and SigComp User Guide:
---------------------------------------------------

The following tests should cover the various compressor-local =
implementation choices described in SigComp-Extended and the SigComp =
User Guide.

Note that "Maintaining State Data Across Application Sessions" from =
SigComp-Extended is an application issue, so it's covered in the =
"application tests".

5.1) Compression algorithms

   This test should check that Endpoint 1 can upload a compression =
algorithm to Endpoint 2 and use it to successfully decompress a message =
flow. Only
   the minimum resources should be available at Endpoint 2 (in =
particular the state_memory_size should be 0 for this test).

   The SigComp User Guide contains bytecode for six example compression =
algorithms - the more of these we can test the better:

   5.1.1) Simplified LZ77
   5.1.2) LZSS
   5.1.3) LZW
   5.1.4) DEFLATE
   5.1.5) LZJH
   5.1.6) EPIC

   Support required at Endpoint 1: Uploading bytecode for the =
compression algorithm. Coping with minimum resources at Endpoint 2.
   Support required at Endpoint 2: Basic SigComp only.

5.2) Additional resources at the receiving endpoint

   This test should check that Endpoint 1 can handle different resource =
allocations at Endpoint 2. In the first instance the additional =
resources can be
   configured manually; a more advanced version of the test can =
announce the extra resources automatically using the feedback =
mechanism:

   5.2.1) Manually configuring both endpoints to make use of the =
additional resources.
   5.2.2) Announcing the additional resources using the SigComp =
feedback mechanism.

   Support required at Endpoint 1: Using extra resources at Endpoint 2 =
to improve the overall compression ratio.
   Support required at Endpoint 2: Making additional resources =
available. Announcing the resources using the SigComp feedback =
mechanism.

5.3) Remote Compressor Initiated Acknowledgements

   This test should check that Endpoint 1 can request a feedback item =
to be returned by Endpoint 2, and that it can make use of the returned =
feedback to
   improve the overall compression ratio (e.g. by accessing states =
acknowledged by the returned feedback).

   Note: Bytecode for using the "Remote Compressor Initiated =
Acknowledgements" is given in the SigComp User Guide.

   Support required at Endpoint 1: Uploading bytecode that requests a =
feedback item to be returned, and making use of the resulting feedback.
   Support required at Endpoint 2: Basic SigComp only.

5.4) Local Endpoint Initiated Acknowledgements

   This test should check that Endpoint 2 can announce the state =
identifiers for any state created by Endpoint 1, and that Endpoint 1 =
can make use of this
   information to improve the overall compression ratio. Note that this =
test provides an alternative feedback mechanism to the "Remote =
Compressor Initiated
   Acknowledgements".

   Note: SigComp-Extended gives an example message format for Local =
Endpoint Initiated Acknowledgements. Whilst this is purely an =
implementation decision,
   it would be a bonus if we can try out this message format as part of =
the test.

   Support required at Endpoint 1: Uploading bytecode to save a state. =
Also understanding the state identifier that is returned.
   Support required at Endpoint 2: Returning the state identifier for =
the saved state.

5.5) Shared Compression

   This test should check that Endpoint 1 can save an uncompressed =
application message as shared state and then announce this state to =
Endpoint 2 using the
   SigComp feedback mechanism. It should also be checked that Endpoint =
2 can understand the announcement and make use of the offered state to =
improve the
   overall compression ratio.

   Note: SigComp-Extended gives an example message format for Shared =
Compression. Whilst this is purely an implementation decision, it would =
be a bonus if
   we can try out this message format as part of the test.

   Support required at Endpoint 1: Saving uncompressed application =
message as state. Announcing shared state ID.
   Support required at Endpoint 2: Understanding the shared state ID =
and making use of the shared state.

5.6) Use of User-Specific Dictionary

   This test should check that Endpoint 1 can upload a user-specific =
dictionary to Endpoint 2, and use it to compress subsequent messages.

   Note: The user-specific dictionary won't help to improve the overall =
compression ratio unless the application messages include realistic =
SIP.

   Support required at Endpoint 1: Uploading the user-specific =
dictionary and making use of it.
   Support required at Endpoint 2: Basic SigComp only.

5.7) Checkpoint State

   This test should check that Endpoint 1 can request a checkpoint =
state to be saved, and can use this state to recover in the event of =
message loss.

   Support required at Endpoint 1: Setting checkpoint =
state_retention_priority to a non-zero value. Using this state to =
recover in the event of message loss.
   Support required at Endpoint 2: Basic SigComp only.

5.8) Implicit Deletion for Dictionary Update

   This test should use a compression algorithm that automatically =
deletes data from the dictionary once it becomes full.

   Note: All six compression algorithms in the SigComp User Guide have =
this feature, so the test just needs to ensure that enough application =
data is sent
   to trigger the implicit deletion of old data from the dictionary.

   Support required at Endpoint 1: Uploading a compression algorithm =
with this feature.
   Support required at Endpoint 2: Basic SigComp only.

5.9) Acknowledgement Optimization

   This test should check that Endpoint 1 can use the acknowledgement =
optimization for shared compression to determine when its state =
creation requests are
   successful.

   Support required at Endpoint 1: As for "shared compression" plus =
maintaining a mapping from the shared state to its own state. Using the =
acked states.
   Support required at Endpoint 2: As for "shared compression".

Static Dictionary:
------------------

6.1) Compressing messages using the static dictionary

   Note: Bytecode for accessing the static dictionary is given in the =
SigComp User Guide. Also note that the static dictionary won't help to =
improve the
   overall compression ratio unless the application messages include =
realistic SIP.

   Support required at Endpoint 1: Configuring the compression =
algorithm to use the static dictionary.
   Support required at Endpoint 2: Having the static dictionary state =
available.

Transport Layer:
----------------

7.1) Support for TCP

   For this test we'll need to rerun some of the above tests using TCP =
as the transport layer rather than UDP. Since the choice of transport =
layer has
   little effect on SigComp operation, rerunning tests 5.1) and 5.2) =
should be sufficient to check that the TCP support is working =
correctly.

Advanced Tests:
---------------

8.1) Running the above mechanisms in parallel.

   The above tests are designed to cover each of the SigComp features =
and options in turn. The next step is to test combinations of these =
features running
   in parallel - e.g. the set of features expected to be deployed in a =
real SigComp implementation.

8.2) Running two or more compressors simultaneously.

   It should be checked that two or more endpoints can communicate with =
the same remote endpoint at the same time, using a separate compartment =
for each.

Application-specific Tests:
---------------------------

The following tests are designed for the components of SigComp that =
require interaction with the application:

9.1) Multiplexing uncompressed messages with SigComp messages.

   Both DAP and SIP should be able to multiplex uncompressed and =
SigComp messages on the same port, using the indicator bit pattern =
present in all SigComp
   messages to distinguish them from uncompressed messages.

9.2) Creating and tearing down compartments.

   DAP contains a field to explicitly instruct the application to =
create or tear down a compartment. Real applications such as SIP should =
be able to do
   this automatically based on information in the application messages.

9.3) SigComp discovery mechanism.

   Robert and Adam have a comprehensive set of tests for discovering =
and enabling SigComp within SIP (see =
http://www.sipit.net/sipit-sigcomp.pdf).

9.4) DoS survival.

   At some stage we'll need to test that SigComp doesn't introduce any =
new security holes in a SIP stack, e.g. by attempting a DoS attack on a =
SigComp-
   enabled SIP stack.
------_=_NextPart_000_01C2C62A.2A14A0DA--
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Mon Jan 27 19:01:57 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01281
	for <rohc-archive@odin.ietf.org>; Mon, 27 Jan 2003 19:01:57 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0S0MdN28733
	for rohc-archive@odin.ietf.org; Mon, 27 Jan 2003 19:22:39 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0S0McJ28730
	for <rohc-web-archive@optimus.ietf.org>; Mon, 27 Jan 2003 19:22:38 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01273
	for <rohc-web-archive@ietf.org>; Mon, 27 Jan 2003 19:01:26 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0S0MSJ28722;
	Mon, 27 Jan 2003 19:22:28 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0S0LSJ28691
	for <rohc@optimus.ietf.org>; Mon, 27 Jan 2003 19:21:28 -0500
Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01252
	for <rohc@ietf.org>; Mon, 27 Jan 2003 19:00:15 -0500 (EST)
From: zhigang.c.liu@nokia.com
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0S03r123114
	for <rohc@ietf.org>; Mon, 27 Jan 2003 18:03:53 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T600b8ca220ac12f254108@davir01nok.americas.nokia.com>;
 Mon, 27 Jan 2003 10:17:06 -0600
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Mon, 27 Jan 2003 10:17:01 -0600
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp interop
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
Date: Mon, 27 Jan 2003 10:17:01 -0600
Message-ID: <DE0842B293FC4847992F9EDF8D72E1ED24A768@daebe005.americas.nokia.com>
Thread-Topic: [rohc] a dummy application protocol (DAP) for SigComp interop
Thread-Index: AcLF97KJfLDy7a+wS+GaPCuQs2tQTQAI2EpQ
To: <Lajos.Zaccomer@eth.ericsson.se>, <rohc@ietf.org>
X-OriginalArrivalTime: 27 Jan 2003 16:17:01.0602 (UTC) FILETIME=[861B5820:01C2C61F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0S0LSJ28692
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

The receiving node is also a sending node. It can can always send a DAP
message in the reverse direction on which sigcomp signals can be piggybacked. 
But you have a good point that it should be made explicit in the DAP.
I'll send a revised version soon.

Zhigang

> -----Original Message-----
> From: ext Lajos Zaccomer (ETH) [mailto:Lajos.Zaccomer@eth.ericsson.se]
> Sent: January 27, 2003 5:30 AM
> To: Liu Zhigang.C (NRC/Dallas); rohc@ietf.org
> Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp
> interop
> 
> 
> Hi,
> 
> How will we test feedback, returned parameters and extended 
> features with DAP? It seems that the receiving node is indeed 
> a receiver and cannot be instructed to send me anything.
> 
> Zacco
> 
> -----Original Message-----
> From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com]
> Sent: Saturday, January 25, 2003 2:04 AM
> To: rohc@ietf.org
> Subject: [rohc] a dummy application protocol (DAP) for SigComp interop
> 
> 
> Hi,
> 
> Attached is a simple protocol that can be used for the 
> interop test during SIPit in February. 
> 
> Your comments are welcome.
> 
> Zhigang
> 
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Mon Jan 27 19:07:38 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01443
	for <rohc-archive@odin.ietf.org>; Mon, 27 Jan 2003 19:07:38 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0S0SKe28949
	for rohc-archive@odin.ietf.org; Mon, 27 Jan 2003 19:28:20 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0S0SKJ28946
	for <rohc-web-archive@optimus.ietf.org>; Mon, 27 Jan 2003 19:28:20 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01428
	for <rohc-web-archive@ietf.org>; Mon, 27 Jan 2003 19:07:06 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0S0S4J28927;
	Mon, 27 Jan 2003 19:28:04 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0S0R1J28879
	for <rohc@optimus.ietf.org>; Mon, 27 Jan 2003 19:27:01 -0500
Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01373
	for <rohc@ietf.org>; Mon, 27 Jan 2003 19:05:47 -0500 (EST)
From: zhigang.c.liu@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0S0Big22881
	for <rohc@ietf.org>; Tue, 28 Jan 2003 02:11:44 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T600ef460c3ac158f24077@esvir04nok.ntc.nokia.com>;
 Tue, 28 Jan 2003 02:09:16 +0200
Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Tue, 28 Jan 2003 02:09:16 +0200
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Mon, 27 Jan 2003 18:09:14 -0600
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_001_01C2C661.7D958226"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp interop
Date: Mon, 27 Jan 2003 18:09:14 -0600
Message-ID: <DE0842B293FC4847992F9EDF8D72E1ED0133DF71@daebe005.americas.nokia.com>
X-MS-Has-Attach: yes
Thread-Topic: [rohc] a dummy application protocol (DAP) for SigComp interop
Thread-Index: AcLF97KJfLDy7a+wS+GaPCuQs2tQTQAI2EpQABEz58A=
To: <Lajos.Zaccomer@eth.ericsson.se>, <rohc@ietf.org>
X-OriginalArrivalTime: 28 Jan 2003 00:09:14.0523 (UTC) FILETIME=[7DD7FEB0:01C2C661]
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C2C661.7D958226
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Here is the revised version of DAP:
- added "need-response" header field
- clarified how to derive a globally unique compartment-ID
- clarified on the "peer compartments"
- renamed "global-ID" to "endpoint-ID"

Please provide your comments promptly. The interop is close
and it would be good to freeze this asap. (Let's keep it
simple for now. We can always improve it later before the=20
next interop.)

BR,
Zhigang

> -----Original Message-----
> From: Liu Zhigang.C (NRC/Dallas)=20
> Sent: January 27, 2003 10:17 AM
> To: 'ext Lajos Zaccomer (ETH)'; rohc@ietf.org
> Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp
> interop
>=20
>=20
> The receiving node is also a sending node. It can can always send a =
DAP
> message in the reverse direction on which sigcomp signals can be =
piggybacked.=20
> But you have a good point that it should be made explicit in the DAP.
> I'll send a revised version soon.
>=20
> Zhigang
>=20
> > -----Original Message-----
> > From: ext Lajos Zaccomer (ETH)=20
> [mailto:Lajos.Zaccomer@eth.ericsson.se]
> > Sent: January 27, 2003 5:30 AM
> > To: Liu Zhigang.C (NRC/Dallas); rohc@ietf.org
> > Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp
> > interop
> >=20
> >=20
> > Hi,
> >=20
> > How will we test feedback, returned parameters and extended=20
> > features with DAP? It seems that the receiving node is indeed=20
> > a receiver and cannot be instructed to send me anything.
> >=20
> > Zacco
> >=20
> > -----Original Message-----
> > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com]
> > Sent: Saturday, January 25, 2003 2:04 AM
> > To: rohc@ietf.org
> > Subject: [rohc] a dummy application protocol (DAP) for=20
> SigComp interop
> >=20
> >=20
> > Hi,
> >=20
> > Attached is a simple protocol that can be used for the=20
> > interop test during SIPit in February.=20
> >=20
> > Your comments are welcome.
> >=20
> > Zhigang
> >=20
>=20

------_=_NextPart_001_01C2C661.7D958226
Content-Type: text/plain;
	name="dap-1b.txt"
Content-Description: dap-1b.txt
Content-Disposition: attachment;
	filename="dap-1b.txt"
Content-Transfer-Encoding: base64

QSBEdW1teSBBcHBsaWNhdGlvbiBQcm90b2NvbCAoREFQKQ0NCi0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NDQoNDQoxLiBJbnRyb2R1Y3Rpb24NDQoNDQpUaGlzIGRvY3VtZW50IGRl
ZmluZXMgYSBzaW1wbGUgZHVtbXkgYXBwbGljYXRpb24gcHJvdG9jb2wgKERBUCkgdGhhdA0NCmNh
biBiZSB1c2VkIGZvciBTaWdDb21wIGludGVyb3BlcmFiaWxpdHkgdGVzdC4gVGhpcyBpcyBoYW5k
eSBmb3INDQpTaWdDb21wIGltcGxlbWVudGF0aW9ucyB0aGF0IGFyZSBub3QgaW50ZWdyYXRlZCB3
aXRoIFNJUCBzdGFjay4gSXQgYWxzbw0NCnByb3ZpZGVzIHNvbWUgZmVhdHVyZXMgdGhhdCBmYWNp
bGl0YXRlIHRoZSB0ZXN0cyBvZiBTaWdDb21wIGludGVybmFsDQ0Kb3BlcmF0aW9ucy4NDQoNDQpU
aGUgbWVzc2FnZSBmb3JtYXQgaXMgcXVpdGUgc2ltcGxlLiBFYWNoIG1lc3NhZ2UgY29uc2lzdHMg
b2YgYSA4LWxpbmUNDQptZXNzYWdlLWhlYWRlciwgYW4gZW1wdHkgbGluZSwgYW5kIGFuIG9wdGlv
bmFsIG1lc3NhZ2UtYm9keS4gWW91IGNhbg0NCnNlZSB0aGUgc3R5bGUgcmVzZW1ibGVzIHRoYXQg
b2YgU0lQIGFuZCBIVFRQLg0NCg0NClRoZSBleGFjdCBtZXNzYWdlIGZvcm1hdCBpcyBnaXZlbiBs
YXRlciBpbiBhdWdtZW50ZWQgQmFja3VzLU5hdXIgRm9ybSANDQooQUJORikgKHNlZSBSRkMgMjIz
NCkuIEhlcmUgYXJlIGEgZmV3IG5vdGVzOg0NCg0NCi0gRWFjaCBsaW5lIG9mIG1lc3NhZ2UtaGVh
ZGVyIG11c3QgYmUgdGVybWluYXRlZCB3aXRoIENSIExGLg0NCi0gVGhlIGVtcHR5IGxpbmUgbXVz
dCBiZSBwcmVzZW50IGV2ZW4gaWYgdGhlIG1lc3NhZ2UtYm9keSBpcyBub3QuDQ0KLSBCb2R5LWxl
bmd0aCBpcyB0aGUgbGVuZ3RoIG9mIHRoZSBtZXNzYWdlLWJvZHksIGV4Y2x1ZGluZyB0aGUgQ1JM
Rg0NCndoaWNoIHNlcGFyYXRlcyB0aGUgbWVzc2FnZS1ib2R5IGZyb20gdGhlIG1lc3NhZ2UtaGVh
ZGVyLg0NCi0gQWxsIHN0cmluZ3MgaW4gbWVzc2FnZS1oZWFkZXIgYXJlIGNhc2UtaW5zZW5zaXRp
dmUuDQ0KLSBGb3IgaW1wbGVtZW50YXRpb24gYWNjb3JkaW5nIHRvIHRoaXMgZG9jdW1lbnQsIHRo
ZSBEQVAtdmVyc2lvbiANDQptdXN0IGJlIHNldCB0byAxLiANDQoNDQoNDQoyLiBQcm9jZXNzaW5n
IGEgREFQIG1lc3NhZ2U6DQ0KDQ0KLSBBIG1lc3NhZ2Ugd2l0aCBpbnZhbGlkIGZvcm1hdCB3aWxs
IGJlIGRpc2NhcmRlZCBieSBhIERBUCByZWNlaXZlcg0NCg0NCi0gRm9yIHRlc3RpbmcgcHVycG9z
ZSwgYSBtZXNzYWdlIHdpdGggdmFsaWQgZm9ybWF0IHdpbGwgYmUgcmV0dXJuZWQgdG8NDQp0aGUg
b3JpZ2luYWwgc2VuZGVyIChJUCBhZGRyZXNzLCBwb3J0IG51bWJlcikgaW4gY2xlYXIgdGV4dCwg
aS5lLiwgDQ0Kd2l0aG91dCBjb21wcmVzc2lvbi4gVGhpcyBpcyB0aGUgY2FzZSBldmVuIGlmIHRo
ZSBzZW5kZXIgcmVxdWVzdHMgdGhlDQ0KcmVjZWl2ZXIgdG8gcmVqZWN0IHRoZSBtZXNzYWdlLg0N
Cg0NCi0gRW5kcG9pbnQtSUQgaXMgdGhlIGdsb2JhbCBpZGVudGlmaWVyIG9mIHRoZSBzZW5kaW5n
IGVuZHBvaW50LiBJdCBjYW4NDQpiZSB1c2VkIHRvIHRlc3QgdGhlIGNhc2Ugd2hlcmUgbXVsdGlw
bGUgU2lnQ29tcCBlbmRwb2ludHMgIGNvbW11bmljYXRlDQ0Kd2l0aCB0aGUgc2FtZSByZW1vdGUg
U2lnQ29tcCBlbmRwb2ludC4gRm9yIHNpbXBsaWNpdHksIElQdjQgYWRkcmVzcyBpcw0NCnVzZWQg
Zm9yIHRoaXMgcHVycG9zZS4gDQ0KW2F1dGhvcidzIG5vdGU6IGRvIHdlIG5lZWQgdG8gaW5jbHVk
ZSBJUHY2IGFkZHJlc3M/XQ0NCg0NCi0gQ29tcGFydG1lbnQtSUQgaXMgdGhlIGlkZW50aWZpZXIg
b2YgdGhlICpjb21wcmVzc29yKiBjb21wYXJ0bWVudA0NCnRoYXQgdGhlICpzZW5kaW5nKiBlbmRw
b2ludCB1c2VkIHRvIGNvbXByZXNzIHRoaXMgbWVzc2FnZS4gSXQgaXMNDQphc3NpZ25lZCBieSB0
aGUgc2VuZGVyIGFuZCB0aGVyZWZvcmUgb25seSB1bmlxdWUgcGVyIHNlbmRpbmcgZW5kcG9pbnQu
DQ0KSS5lLiwgREFQIG1lc3NhZ2VzICBzZW50IGJ5IGRpZmZlcmVudCBlbmRwb2ludHMgbWF5IGNh
cnJ5IHNhbWUNDQpjb21wYXJ0bWVudC1JRC4gVGhlcmVmb3JlLCB0aGUgcmVjZWl2ZXIgc2hvdWxk
IHVzZSB0aGUgKGVuZHBvaW50LUlELA0NCmNvbXBhcnRtZW50LUlEKSBwYWlyIGNhcnJpZWQgaW4g
YSBtZXNzYWdlIHRvIGRldGVybWluZSB0aGUgZGVjb21wcmVzc29yDQ0KY29tcGFydG1lbnQgaWRl
bnRpZmllciBmb3IgdGhhdCBtZXNzYWdlLiBUaGUgZXhhY3QgbG9jYWwgcmVwcmVzZW50YXRpb24N
DQpvZiB0aGUgZGVyaXZlZCBjb21wYXJ0bWVudCBpZGVudGlmaWVyIGlzIGFuIGltcGxlbWVudGF0
aW9uIGlzc3VlLg0NCg0NCi0gVG8gdGVzdCBTaWdDb21wIGZlZWRiYWNrIChSRkMgMzMyMCwgc2Vj
dGlvbiAzLjEpLCBwZWVyIGNvbXBhcnRtZW50cyANDQpiZXR3ZWVuIHR3byBlbmRwb2ludHMgYXJl
IGRlZmluZWQgaW4gREFQIGFzIHRob3NlIHdpdGggdGhlIHNhbWUNDQpjb21wYXJ0bWVudC1JRC4g
Rm9yIGV4YW1wbGUsIChlbmRwb2ludC1BLCAxKSBhbmQgKGVuZHBvaW50LUIsIDEpIGFyZQ0NCnBl
ZXIgY29tcGFydG1lbnRzLiBUaGF0IG1lYW5zLCBTaWdDb21wIGZlZWRiYWNrIGZvciBhIERBUCBt
ZXNzYWdlIHNlbnQNDQpmcm9tIGNvbXBhcnRtZW50IDEgb2YgZW5kcG9pbnQtQSB0byBlbmRwb2lu
dC1CIG11c3QgYmUgcGlnZ3liYWNrZWQgb24gYQ0NCkRBUCBtZXNzYWdlIHNlbnQgZnJvbSBjb21w
YXJ0bWVudCAxIG9mIGVuZHBvaW50LUIgdG8gZW5kcG9pbnQtQS4NDQoNDQotIEEgREFQIHJlY2Vp
dmVyIHdpbGwgZm9sbG93IHRoZSBpbnN0cnVjdGlvbiBjYXJyaWVkIGluIGhlYWRlciBsaW5lLTUN
DQp0byBlaXRoZXIgYWNjZXB0IG9yIHJlamVjdCBhIERBUCBtZXNzYWdlLiBOb3RlOiBsaW5lLTYg
YW5kIGxpbmUtNyB3aWxsDQ0KYmUgaWdub3JlZCBpZiB0aGUgbWVzc2FnZSBpcyByZWplY3RlZC4N
DQoNDQotIEEgREFQIHJlY2VpdmVyIHdpbGwgZm9sbG93IHRoZSBpbnN0cnVjdGlvbiBpbiBsaW5l
LTYgdG8gY3JlYXRlIG9yDQ0KY2xvc2UgdGhlIGRlY29tcHJlc3NvciBjb21wYXJ0bWVudCB0aGF0
IGlzIGFzc29jaWF0ZWQgd2l0aCB0aGUgcmVjZWl2ZWQNDQpEQVAgbWVzc2FnZSAoc2VlIGFib3Zl
KS4gDQ0KDQ0KLSBJZiB0aGUgaGVhZGVyIGxpbmUtNyBvZiBhIHJlY2VpdmVkIERBUCBtZXNzYWdl
IGNhcnJpZXMgIlRSVUUiLCB0aGUNDQpyZWNlaXZlciB3aWxsIHNlbmQgYmFjayBhIHJlc3BvbnNl
IG1lc3NhZ2UgdG8gdGhlIHNlbmRlci4gQXMgbWVudGlvbmVkDQ0KYWJvdmUsIHRoZSByZXNwb25z
ZSBtZXNzYWdlIG11c3QgYmUgY29tcHJlc3NlZCBieSBhbmQgc2VudCBmcm9tIHRoZQ0NCmxvY2Fs
IGNvbXByZXNzb3IgY29tcGFydG1lbnQgdGhhdCBpcyBwZWVyIG9mIHRoZSByZW1vdGUgY29tcHJl
c3Nvcg0NCmNvbXBhcnRtZW50LiBPdGhlciB0aGFuIHRoaXMgY29uc3RyYWludCwgdGhlIHJlc3Bv
bnNlIG1lc3NhZ2UgY2FuIGNhcnJ5DQ0KYXJiaXRyYXJ5IG1lc3NhZ2UtaGVhZGVyIGFuZCBtZXNz
YWdlLWJvZHkuIEZvciBleGFtcGxlLCB0aGUgDQ0KIm5lZWQtcmVzcG9uc2UiIGZpZWxkIG9mIHRo
ZSByZXNwb25zZSBjYW4gYWxzbyBiZSBzZXQgdG8gVFJVRSwgd2hpY2gNDQp3aWxsIHRyaWdnZXIg
YSByZXNwb25zZSB0byByZXNwb25zZSwgYW5kIHNvIG9uLiBDYXJlIG11c3QgYmUgdGFrZW4gaW4N
DQppbXBsZW1lbnRhdGlvbiB0byBhdm9pZCBkZWFkIGxvb3AuIEZvciB0ZXN0aW5nLCB0aGUgbWVz
c2FnZS1ib2R5IG9mIGENDQpyZXNwb25zZSBtYXkgY29udGFpbiB0aGUgbWVzc2FnZS1oZWFkZXIg
b2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UgdGhhdA0NCnRyaWdnZXJlZCB0aGUgcmVzcG9uc2UuDQ0K
DQ0KLSBNZXNzYWdlLXNlcSBjYW4gYmUgdXNlZCBieSBhIERBUCBzZW5kZXIgdG8gdHJhY2sgZWFj
aCBtZXNzYWdlIGl0DQ0Kc2VuZHMsIGUuZy4sIGluIGNhc2Ugb2YgbG9zc2VzLiBNZXNzYWdlIGxv
c3MgY2FuIGhhcHBlbiBlaXRoZXIgb24gdGhlDQ0KcGF0aCBvciBhdCB0aGUgcmVjZWl2aW5nIGVu
ZHBvaW50IChpLmUuIGR1ZSB0byBkZWNvbXByZXNzaW9uIGZhaWx1cmUpLg0NClRoZSBhc3NpZ25t
ZW50IG9mIG1lc3NhZ2Utc2VxIGlzIHVwIHRvIHRoZSBzZW5kZXIuIEZvciBleGFtcGxlLCBpdA0N
CmNvdWxkIGJlIGVpdGhlciBhc3NpZ25lZCBwZXIgY29tcGFydG1lbnQgb3IgcGVyIGVuZHBvaW50
LiBUaGlzIGhhcyBubw0NCmltcGFjdCBvbiB0aGUgcmVjZWl2aW5nIHNpZGUuDQ0KDQ0KDQ0KMy4g
REFQIG1lc3NhZ2UgZm9ybWF0IGluIEFCTkYNDQoNDQooTm90ZTogc2VlIFJGQyAyMjM0IGZvciBi
YXNpYyBydWxlcy4pDQ0KDQ0KREFQLW1lc3NhZ2UgPSBtZXNzYWdlLWhlYWRlcg0NCiAgICAgICAg
ICAgICAgQ1JMRg0NCiAgICAgICAgICAgICAgWyBtZXNzYWdlLWJvZHkgXQ0NCg0NCm1lc3NhZ2Ut
Ym9keSA9ICpPQ1RFVA0NCg0NCm1lc3NhZ2UtaGVhZGVyID0gbGluZS0xIGxpbmUtMiBsaW5lLTMg
bGluZS00IGxpbmUtNSBsaW5lLTYgbGluZS03IGxpbmUtOA0NCg0NCmxpbmUtMSA9ICJEQVAtdmVy
c2lvbiIgIjoiIDEqRElHSVQgQ1JMRg0NCmxpbmUtMiA9ICJlbmRwb2ludC1JRCIgIjoiIElQdjRh
ZGRyZXNzIENSTEYNDQpsaW5lLTMgPSAiY29tcGFydG1lbnQtSUQiICI6IiAxKkRJR0lUIENSTEYN
DQpsaW5lLTQgPSAibWVzc2FnZS1zZXEiICI6IiAxKkRJR0lUIENSTEYNDQpsaW5lLTUgPSAibWVz
c2FnZS1hdXRoIiAiOiIgKCAiQUNDRVBUIiAvICJSRUpFQ1QiICkgQ1JMRg0NCmxpbmUtNiA9ICJj
b21wYXJ0bWVudC1vcCIgIjoiICggIkNSRUFURSIgLyAiQ0xPU0UiIC8gIk5PTkUiICkgQ1JMRg0N
CmxpbmUtNyA9ICJuZWVkLXJlc3BvbnNlIiAiOiIgKCAiVFJVRSIgLyAiRkFMU0UiICkNDQpsaW5l
LTggPSAiYm9keS1sZW5ndGgiICI6IiAxKkRJR0lUIENSTEYNDQoNDQpJUHY0YWRkcmVzcyA9IDEq
M0RJR0lUICIuIiAxKjNESUdJVCAiLiIgMSozRElHSVQgIi4iIDEqM0RJR0lUDQ0KDQ0KDQ0KNC4g
QW4gZXhhbXBsZSBvZiBhIERBUCBtZXNzYWdlDQ0KDQ0KREFQLXZlcnNpb246IDENDQplbmRwb2lu
dC1JRDogMTIzLjQ1LjY3Ljg5DQ0KY29tcGFydG1lbnQtSUQ6IDINDQptZXNzYWdlLXNlcTogMA0N
Cm1lc3NhZ2UtYXV0aDogQUNDRVBUDQ0KY29tcGFydG1lbnQtb3A6IENSRUFURQ0NCm5lZWQtcmVz
cG9uc2U6IFRSVUUNDQpib2R5LWxlbmd0aDogMjI4DQ0KDQ0KVGhpcyBpcyBhIERBUCBtZXNzYWdl
IHNlbnQgZnJvbSBTaWdDb21wIGVuZHBvaW50IGF0IElQIGFkZHJlc3MNDQoxMjMuNDUuNjcuODku
IFRoaXMgaXMgdGhlIGZpcnN0IG1lc3NhZ2Ugc2VudCBmcm9tIGNvbXBhcnRtZW50IDIuDQ0KUGxl
YXNlIGFjY2VwdCB0aGUgbWVzc2FnZSwgY3JlYXRlIHRoZSBhc3NvY2lhdGVkIGNvbXBhcnRtZW50
LA0NCmFuZCBzZW5kIGJhY2sgYSByZXNwb25zZSBtZXNzYWdlLg==

------_=_NextPart_001_01C2C661.7D958226--
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Mon Jan 27 20:30:43 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02416
	for <rohc-archive@odin.ietf.org>; Mon, 27 Jan 2003 20:30:42 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0S1pQ600989
	for rohc-archive@odin.ietf.org; Mon, 27 Jan 2003 20:51:26 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0S1pQJ00986
	for <rohc-web-archive@optimus.ietf.org>; Mon, 27 Jan 2003 20:51:26 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02401
	for <rohc-web-archive@ietf.org>; Mon, 27 Jan 2003 20:30:11 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0S1pEJ00912;
	Mon, 27 Jan 2003 20:51:14 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0S1orJ00885
	for <rohc@optimus.ietf.org>; Mon, 27 Jan 2003 20:50:53 -0500
Received: from dyn-tx-app-007.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02374
	for <rohc@ietf.org>; Mon, 27 Jan 2003 20:29:38 -0500 (EST)
Received: from TXADAM (localhost.localdomain [127.0.0.1])
	by dyn-tx-app-007.dfw.dynamicsoft.com (8.12.5/8.12.5) with SMTP id h0S1X69Z027057;
	Mon, 27 Jan 2003 19:33:07 -0600
Message-ID: <01a701c2c66d$27a058b0$6601a8c0@dynamicsoft.com>
From: "Adam Roach" <adam@dynamicsoft.com>
To: <zhigang.c.liu@nokia.com>, <Lajos.Zaccomer@eth.ericsson.se>,
        <rohc@ietf.org>
References: <DE0842B293FC4847992F9EDF8D72E1ED0133DF71@daebe005.americas.nokia.com>
Subject: Re: [rohc] a dummy application protocol (DAP) for SigComp interop
Date: Mon, 27 Jan 2003 19:32:42 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2720.3000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

<zhigang.c.liu@nokia.com> writes:

> - added "need-response" header field

I thought we had discussed having a *counter*, not a TRUE/FALSE value.
That way, you can avoid accidental infinite loops, *and* it makes it much
easier to run a test of, say, 4 back-and-forth messages (e.g. to retrive
state) than a simple TRUE/FALSE. Here's some text.

line-7 = "hops-left" ":" 1*digit

- If the header line-7 of a received DAP message is greater than zero, the
receiver will send back a response message to the sender. As mentioned
above, the response message must be compressed by and sent from the
local compressor compartment that is peer of the remote compressor
compartment. Line-7 of the response message will carry the value that
is one less than the value of line-7 from the received message.
Other than these constraints, the response message can carry
arbitrary message-header and message-body. For testing, the
message-body of a response may contain the message-header
of the original message that triggered the response.


/a


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



From mailnull@www1.ietf.org  Tue Jan 28 02:51:53 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18748
	for <rohc-archive@odin.ietf.org>; Tue, 28 Jan 2003 02:51:53 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0S8CjK32151
	for rohc-archive@odin.ietf.org; Tue, 28 Jan 2003 03:12:45 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0S8CjJ32148
	for <rohc-web-archive@optimus.ietf.org>; Tue, 28 Jan 2003 03:12:45 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18739
	for <rohc-web-archive@ietf.org>; Tue, 28 Jan 2003 02:51:22 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0S8CXJ32137;
	Tue, 28 Jan 2003 03:12:33 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0S8BSJ32099
	for <rohc@optimus.ietf.org>; Tue, 28 Jan 2003 03:11:28 -0500
Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18714
	for <rohc@ietf.org>; Tue, 28 Jan 2003 02:50:04 -0500 (EST)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0S7rZKV010319;
	Tue, 28 Jan 2003 08:53:35 +0100 (MET)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <DY5RL9LS>; Tue, 28 Jan 2003 08:53:09 +0100
Message-ID: <F005CD411D18D3119C8F00508B0874800A14469E@ehubunt100.eth.ericsson.se>
From: "Lajos Zaccomer (ETH)" <Lajos.Zaccomer@eth.ericsson.se>
To: "'Price, Richard'" <richard.price@roke.co.uk>,
        "'rohc@ietf.org'"
	 <rohc@ietf.org>
Subject: RE: [rohc] SigComp Interop
Date: Tue, 28 Jan 2003 08:51:26 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi,

Thank you for the answers Richard, but it is as I feared, I need further explanations (see below):

-----Original Message-----
From: Price, Richard [mailto:richard.price@roke.co.uk]
Sent: Monday, January 27, 2003 6:33 PM
To: 'rohc@ietf.org'
Subject: [rohc] SigComp Interop


Hi,

Attached is a first attempt at a test suite for the SigComp Interop.
Comments welcome!

Regards,

Richard

P.S. I also have a few answers to some issues raised in the original
proposal from Zacco:

> 1.2. Check if compressor and decompressor uses the same or separate
> state memory. (not specified in standard)

This should be covered by the following text from Section 6.2 of SigComp:

   Note that locally available state items (as described in Section
   3.3.3) need not be mapped to any particular compartment.  However, if
   they are created on a per-compartment basis, then they must not
   interfere with the state created at the request of the remote
   endpoint.  The special state_retention_priority of 65535 is reserved
   for locally available state items to ensure that this is the case.

So a compressor can create its own state in the state memory reserved for
the decompressor, but it must use the special state_retention_priority
of 65535. This makes sure that if the state memory runs out then the
state created by the compressor is discarded first (otherwise messages
might not decompress correctly).

[L.Z.] This is a serious disadvantage, because the compressor may not be sure how much memory is still available in the remote endpoint as its compressor using shared and/or dynamic compression might save states, which the local endpoint's compressor will not know about. This makes tracking the memory usage impossible, and thus the compressor may not be sure if the message can be decompressed successfully.


> 2.1. Using shared state
> Calculation of shared state ID (not exactly specified in the
> draft, what to test?)

The contents of the shared state (and consequently the shared state ID)
should be exactly specified by RFC 3321. What the interop should test is
that Endpoint 1 can save a shared state and announce the corresponding
state ID to Endpoint 2, which then makes use of the state to improve the
overall compression ratio. The exact message format used to achieve this
is an implementation decision, but if any implementations can test the
example format given in RFC 3321 then that would be a bonus.

[L.Z.] In RFC 3221, the minimum access length with that the shared state ID should be calculated is not specified.

> 2.3. Using local endpoint initiated explicit acknowledgement
> What state ID is handled as an acked_state_id? (not specified in draft)

The acked_state_id can carry the ID of any state previously created by
the decompressor (in other words it's an alternative to using the
requested and returned SigComp feedback to acknowledge states).

[L.Z.] It's easy to say any, and it's also easy to implement. But in this case the remote endpoint may think differently of how to interpret an acked state ID. Let us suppose a bytecode saves two states, one for the bytecode and one for the part of the uncompressed message that remained in the UDVM memory. Which state ID is sent back as an acked state ID?

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



From mailnull@www1.ietf.org  Tue Jan 28 04:17:15 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19631
	for <rohc-archive@odin.ietf.org>; Tue, 28 Jan 2003 04:17:15 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0S9c7L04911
	for rohc-archive@odin.ietf.org; Tue, 28 Jan 2003 04:38:07 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0S9c7J04908
	for <rohc-web-archive@optimus.ietf.org>; Tue, 28 Jan 2003 04:38:07 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19628
	for <rohc-web-archive@ietf.org>; Tue, 28 Jan 2003 04:16:44 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0S9bMJ04766;
	Tue, 28 Jan 2003 04:37:22 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0S9aHJ04200
	for <rohc@optimus.ietf.org>; Tue, 28 Jan 2003 04:36:17 -0500
Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19616
	for <rohc@ietf.org>; Tue, 28 Jan 2003 04:14:54 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <CN3DAD1X>; Tue, 28 Jan 2003 09:18:23 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED41804B885E9@rsys002a.roke.co.uk>
From: "Surtees, Abigail" <abigail.surtees@roke.co.uk>
To: "'Adam Roach'" <adam@dynamicsoft.com>, zhigang.c.liu@nokia.com,
        Lajos.Zaccomer@eth.ericsson.se, rohc@ietf.org
Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp interop
Date: Tue, 28 Jan 2003 09:18:22 -0000
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-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi, 

The DAP looks good to me.  I do have a couple of comments:

I think for that for the first version we don't need to worry about IPv6 addresses.

When the messages are returned in plain text to the compressor, do they have a DAP header on them?

I think we should keep it simple and that a true/false need response field is sufficient for the first testing event.  If we want to write a second version that is more complicated then we could do so at a later date.

Best regards,

Abbie 

>-----Original Message-----
>From: Adam Roach [mailto:adam@dynamicsoft.com]
>Sent: 28 January 2003 01:33
>To: zhigang.c.liu@nokia.com; Lajos.Zaccomer@eth.ericsson.se;
>rohc@ietf.org
>Subject: Re: [rohc] a dummy application protocol (DAP) for SigComp
>interop
>
>
><zhigang.c.liu@nokia.com> writes:
>
>> - added "need-response" header field
>
>I thought we had discussed having a *counter*, not a TRUE/FALSE value.
>That way, you can avoid accidental infinite loops, *and* it 
>makes it much
>easier to run a test of, say, 4 back-and-forth messages (e.g. 
>to retrive
>state) than a simple TRUE/FALSE. Here's some text.
>
>line-7 = "hops-left" ":" 1*digit
>
>- If the header line-7 of a received DAP message is greater 
>than zero, the
>receiver will send back a response message to the sender. As mentioned
>above, the response message must be compressed by and sent from the
>local compressor compartment that is peer of the remote compressor
>compartment. Line-7 of the response message will carry the value that
>is one less than the value of line-7 from the received message.
>Other than these constraints, the response message can carry
>arbitrary message-header and message-body. For testing, the
>message-body of a response may contain the message-header
>of the original message that triggered the response.
>
>
>/a
>
>
>_______________________________________________
>Rohc mailing list
>Rohc@ietf.org
>https://www1.ietf.org/mailman/listinfo/rohc
>
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Tue Jan 28 09:15:34 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26263
	for <rohc-archive@odin.ietf.org>; Tue, 28 Jan 2003 09:15:34 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0SEaXi22419
	for rohc-archive@odin.ietf.org; Tue, 28 Jan 2003 09:36:33 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SEaXJ22415
	for <rohc-web-archive@optimus.ietf.org>; Tue, 28 Jan 2003 09:36:33 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26255
	for <rohc-web-archive@ietf.org>; Tue, 28 Jan 2003 09:15:03 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SEaKJ22407;
	Tue, 28 Jan 2003 09:36:20 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SEa0J22377
	for <rohc@optimus.ietf.org>; Tue, 28 Jan 2003 09:36:00 -0500
Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26243
	for <rohc@ietf.org>; Tue, 28 Jan 2003 09:14:30 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <CN3DAD7D>; Tue, 28 Jan 2003 14:18:00 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1A0@rsys002a.roke.co.uk>
From: "Price, Richard" <richard.price@roke.co.uk>
To: "'Lajos Zaccomer (ETH)'" <Lajos.Zaccomer@eth.ericsson.se>,
        "'rohc@ietf.org'" <rohc@ietf.org>
Subject: RE: [rohc] SigComp Interop
Date: Tue, 28 Jan 2003 14:17:59 -0000
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-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

> > 1.2. Check if compressor and decompressor uses the same or separate
> > state memory. (not specified in standard)
> 
> This should be covered by the following text from Section 6.2 
> of SigComp:
> 
>    Note that locally available state items (as described in Section
>    3.3.3) need not be mapped to any particular compartment. However, if
>    they are created on a per-compartment basis, then they must not
>    interfere with the state created at the request of the remote
>    endpoint.  The special state_retention_priority of 65535 is reserved
>    for locally available state items to ensure that this is the case.
> 
> So a compressor can create its own state in the state memory reserved for
> the decompressor, but it must use the special state_retention_priority
> of 65535. This makes sure that if the state memory runs out then the
> state created by the compressor is discarded first (otherwise messages
> might not decompress correctly).
> 
> [L.Z.] This is a serious disadvantage, because the compressor 
> may not be sure how much memory is still available in the 
> remote endpoint as its compressor using shared and/or dynamic 
> compression might save states, which the local endpoint's 
> compressor will not know about. This makes tracking the 
> memory usage impossible, and thus the compressor may not be 
> sure if the message can be decompressed successfully.

Hi Zacco,

I think that the confusion with this issue is that what you call the
"local endpoint", I'm calling the "remote endpoint" and vice versa.
On my part I'm using the term "local endpoint" to mean the endpoint
that is actually saving the state. The "remote endpoint" is the one that
asks for new state to be created, and makes use of the state to improve
the overall compression ratio.

In order to ensure successful decompression, the remote endpoint must
always know how much state memory is available at the local endpoint (in
case it wants to ask for more state to be created). Consequently, any
states created by the local endpoint *must not* prevent the remote
endpoint from tracking how much state memory is left - in particular
a state creation request by the remote endpoint must not fail because
the local endpoint has filled up the state memory with its own state
(e.g. shared state) that the remote endpoint doesn't know about.

The solution is to give the state created at the request of the remote
endpoint a higher priority than any state created locally. This ensures
that if the state memory becomes full, any state created by the local
endpoint will be pushed out invisibly without interfering with the
remote endpoint's view of how much state memory is left.

> > 2.1. Using shared state
> > Calculation of shared state ID (not exactly specified in the
> > draft, what to test?)
> 
> The contents of the shared state (and consequently the shared state ID)
> should be exactly specified by RFC 3321. What the interop should test is
> that Endpoint 1 can save a shared state and announce the corresponding
> state ID to Endpoint 2, which then makes use of the state to improve the
> overall compression ratio. The exact message format used to achieve this
> is an implementation decision, but if any implementations can test the
> example format given in RFC 3321 then that would be a bonus.
> 
> [L.Z.] In RFC 3221, the minimum access length with that the 
> shared state ID should be calculated is not specified.

The minimum access length is up to the implementer, depending on how much
protection is needed against malicious users attempting to access the
shared state. If security isn't a problem then use the smallest possible
value (namely 6 bytes).

> > 2.3. Using local endpoint initiated explicit acknowledgement
> > What state ID is handled as an acked_state_id? (not 
> specified in draft)
> 
> The acked_state_id can carry the ID of any state previously created by
> the decompressor (in other words it's an alternative to using the
> requested and returned SigComp feedback to acknowledge states).
> 
> [L.Z.] It's easy to say any, and it's also easy to implement. 
> But in this case the remote endpoint may think differently of 
> how to interpret an acked state ID.

From the perspective of the remote endpoint it makes no difference what
is carried in the acked state ID. The endpoint just keeps a list of
the states it would like to use for compression (including the states it
previously created, shared states, well-known compression algorithms
etc.). If the state ID for one of these states is announced then it
marks the state as "available" and uses it to compress messages.

> Let us suppose a bytecode saves two states, one for the bytecode and
> one for the part of the uncompressed message that remained in the UDVM
> memory. Which state ID is sent back as an acked state ID?

That's up to the local endpoint - whichever it thinks will be more
useful for the remote endpoint to receive. To be on the safe side it
could even send both (this means that the example header given in RFC
3321 would need to be rewritten, but this is no problem because the
precise format of the header is also up to the local endpoint).

Regards,

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



From mailnull@www1.ietf.org  Tue Jan 28 09:26:27 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26524
	for <rohc-archive@odin.ietf.org>; Tue, 28 Jan 2003 09:26:27 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0SElQO23593
	for rohc-archive@odin.ietf.org; Tue, 28 Jan 2003 09:47:26 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SElQJ23590
	for <rohc-web-archive@optimus.ietf.org>; Tue, 28 Jan 2003 09:47:26 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26506
	for <rohc-web-archive@ietf.org>; Tue, 28 Jan 2003 09:25:55 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SElCJ23571;
	Tue, 28 Jan 2003 09:47:12 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SEkeJ23496
	for <rohc@optimus.ietf.org>; Tue, 28 Jan 2003 09:46:40 -0500
Received: from rsys002a.roke.co.uk (rsys002a.roke.co.uk [193.118.192.251])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26478
	for <rohc@ietf.org>; Tue, 28 Jan 2003 09:25:09 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <CN3DAD7D>; Tue, 28 Jan 2003 14:18:00 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1A0@rsys002a.roke.co.uk>
From: "Price, Richard" <richard.price@roke.co.uk>
To: "'Lajos Zaccomer (ETH)'" <Lajos.Zaccomer@eth.ericsson.se>,
        "'rohc@ietf.org'" <rohc@ietf.org>
Subject: RE: [rohc] SigComp Interop
Date: Tue, 28 Jan 2003 14:17:59 -0000
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-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

> > 1.2. Check if compressor and decompressor uses the same or separate
> > state memory. (not specified in standard)
> 
> This should be covered by the following text from Section 6.2 
> of SigComp:
> 
>    Note that locally available state items (as described in Section
>    3.3.3) need not be mapped to any particular compartment. However, if
>    they are created on a per-compartment basis, then they must not
>    interfere with the state created at the request of the remote
>    endpoint.  The special state_retention_priority of 65535 is reserved
>    for locally available state items to ensure that this is the case.
> 
> So a compressor can create its own state in the state memory reserved for
> the decompressor, but it must use the special state_retention_priority
> of 65535. This makes sure that if the state memory runs out then the
> state created by the compressor is discarded first (otherwise messages
> might not decompress correctly).
> 
> [L.Z.] This is a serious disadvantage, because the compressor 
> may not be sure how much memory is still available in the 
> remote endpoint as its compressor using shared and/or dynamic 
> compression might save states, which the local endpoint's 
> compressor will not know about. This makes tracking the 
> memory usage impossible, and thus the compressor may not be 
> sure if the message can be decompressed successfully.

Hi Zacco,

I think that the confusion with this issue is that what you call the
"local endpoint", I'm calling the "remote endpoint" and vice versa.
On my part I'm using the term "local endpoint" to mean the endpoint
that is actually saving the state. The "remote endpoint" is the one that
asks for new state to be created, and makes use of the state to improve
the overall compression ratio.

In order to ensure successful decompression, the remote endpoint must
always know how much state memory is available at the local endpoint (in
case it wants to ask for more state to be created). Consequently, any
states created by the local endpoint *must not* prevent the remote
endpoint from tracking how much state memory is left - in particular
a state creation request by the remote endpoint must not fail because
the local endpoint has filled up the state memory with its own state
(e.g. shared state) that the remote endpoint doesn't know about.

The solution is to give the state created at the request of the remote
endpoint a higher priority than any state created locally. This ensures
that if the state memory becomes full, any state created by the local
endpoint will be pushed out invisibly without interfering with the
remote endpoint's view of how much state memory is left.

> > 2.1. Using shared state
> > Calculation of shared state ID (not exactly specified in the
> > draft, what to test?)
> 
> The contents of the shared state (and consequently the shared state ID)
> should be exactly specified by RFC 3321. What the interop should test is
> that Endpoint 1 can save a shared state and announce the corresponding
> state ID to Endpoint 2, which then makes use of the state to improve the
> overall compression ratio. The exact message format used to achieve this
> is an implementation decision, but if any implementations can test the
> example format given in RFC 3321 then that would be a bonus.
> 
> [L.Z.] In RFC 3221, the minimum access length with that the 
> shared state ID should be calculated is not specified.

The minimum access length is up to the implementer, depending on how much
protection is needed against malicious users attempting to access the
shared state. If security isn't a problem then use the smallest possible
value (namely 6 bytes).

> > 2.3. Using local endpoint initiated explicit acknowledgement
> > What state ID is handled as an acked_state_id? (not 
> specified in draft)
> 
> The acked_state_id can carry the ID of any state previously created by
> the decompressor (in other words it's an alternative to using the
> requested and returned SigComp feedback to acknowledge states).
> 
> [L.Z.] It's easy to say any, and it's also easy to implement. 
> But in this case the remote endpoint may think differently of 
> how to interpret an acked state ID.

From the perspective of the remote endpoint it makes no difference what
is carried in the acked state ID. The endpoint just keeps a list of
the states it would like to use for compression (including the states it
previously created, shared states, well-known compression algorithms
etc.). If the state ID for one of these states is announced then it
marks the state as "available" and uses it to compress messages.

> Let us suppose a bytecode saves two states, one for the bytecode and
> one for the part of the uncompressed message that remained in the UDVM
> memory. Which state ID is sent back as an acked state ID?

That's up to the local endpoint - whichever it thinks will be more
useful for the remote endpoint to receive. To be on the safe side it
could even send both (this means that the example header given in RFC
3321 would need to be rewritten, but this is no problem because the
precise format of the header is also up to the local endpoint).

Regards,

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



From mailnull@www1.ietf.org  Tue Jan 28 10:49:48 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28779
	for <rohc-archive@odin.ietf.org>; Tue, 28 Jan 2003 10:49:48 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0SGAmV30399
	for rohc-archive@odin.ietf.org; Tue, 28 Jan 2003 11:10:48 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SGAmJ30396
	for <rohc-web-archive@optimus.ietf.org>; Tue, 28 Jan 2003 11:10:48 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28738
	for <rohc-web-archive@ietf.org>; Tue, 28 Jan 2003 10:49:17 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SGAXJ30343;
	Tue, 28 Jan 2003 11:10:33 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SG9fJ30252
	for <rohc@optimus.ietf.org>; Tue, 28 Jan 2003 11:09:41 -0500
Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28588
	for <rohc@ietf.org>; Tue, 28 Jan 2003 10:47:59 -0500 (EST)
From: zhigang.c.liu@nokia.com
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0SFosB20645
	for <rohc@ietf.org>; Tue, 28 Jan 2003 09:51:09 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T60109a8b83ac12f255108@davir02nok.americas.nokia.com>;
 Tue, 28 Jan 2003 09:50:24 -0600
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Tue, 28 Jan 2003 09:50:17 -0600
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp interop
Date: Tue, 28 Jan 2003 09:50:16 -0600
Message-ID: <DE0842B293FC4847992F9EDF8D72E1ED24A76F@daebe005.americas.nokia.com>
Thread-Topic: [rohc] a dummy application protocol (DAP) for SigComp interop
Thread-Index: AcLGrkJrUV0Pi/k8TfOpjvCYopZT2QANJiUw
To: <abigail.surtees@roke.co.uk>, <adam@dynamicsoft.com>,
        <Lajos.Zaccomer@eth.ericsson.se>, <rohc@ietf.org>
X-OriginalArrivalTime: 28 Jan 2003 15:50:17.0391 (UTC) FILETIME=[F455EBF0:01C2C6E4]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0SG9fJ30253
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Abbie,

> I think for that for the first version we don't need to worry 
> about IPv6 addresses.

OK, that's what I thought too. 
 
> When the messages are returned in plain text to the 
> compressor, do they have a DAP header on them?

Yes, the entire DAP messages (message-header + CRLF + message-body)
are returned. This allows the sender to verify exactly what it has sent.

> I think we should keep it simple and that a true/false need 
> response field is sufficient for the first testing event.  If 
> we want to write a second version that is more complicated 
> then we could do so at a later date.

I agree. 

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



From mailnull@www1.ietf.org  Tue Jan 28 11:50:26 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00953
	for <rohc-archive@odin.ietf.org>; Tue, 28 Jan 2003 11:50:26 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0SHBRk03322
	for rohc-archive@odin.ietf.org; Tue, 28 Jan 2003 12:11:27 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SHBRJ03319
	for <rohc-web-archive@optimus.ietf.org>; Tue, 28 Jan 2003 12:11:27 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00944
	for <rohc-web-archive@ietf.org>; Tue, 28 Jan 2003 11:49:55 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SHBBJ03240;
	Tue, 28 Jan 2003 12:11:11 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SH6MJ02051
	for <rohc@optimus.ietf.org>; Tue, 28 Jan 2003 12:06:22 -0500
Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00793
	for <rohc@ietf.org>; Tue, 28 Jan 2003 11:44:39 -0500 (EST)
From: zhigang.c.liu@nokia.com
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0SGltB02220
	for <rohc@ietf.org>; Tue, 28 Jan 2003 10:48:00 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T6010b8997bac12f255108@davir02nok.americas.nokia.com>;
 Tue, 28 Jan 2003 10:23:13 -0600
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Tue, 28 Jan 2003 08:23:13 -0800
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp interop
Date: Tue, 28 Jan 2003 10:23:12 -0600
Message-ID: <DE0842B293FC4847992F9EDF8D72E1ED24A770@daebe005.americas.nokia.com>
Thread-Topic: [rohc] a dummy application protocol (DAP) for SigComp interop
Thread-Index: AcLGbU4JAZt1ScwcQGypeT2nE0RvEAAd5tLw
To: <adam@dynamicsoft.com>, <Lajos.Zaccomer@eth.ericsson.se>, <rohc@ietf.org>
X-OriginalArrivalTime: 28 Jan 2003 16:23:13.0734 (UTC) FILETIME=[8E53EE60:01C2C6E9]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0SH6MJ02052
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

> I thought we had discussed having a *counter*, not a TRUE/FALSE value.
> That way, you can avoid accidental infinite loops, *and* it 
> makes it much easier to run a test of, say, 4 back-and-forth messages (e.g. 
> to retrive state) than a simple TRUE/FALSE. Here's some text.

Adam,

I cannot recall we discussed about a counter, perhaps I missed that part.

It seems to me that counter is not necessarily better than a simple
TRUE/FALSE toggle:

- To cut an infinite loop, any of the two endpoints can set need-response
to FALSE. That is no more difficult than checking the counter value and 
then decrementing it.

- To have a 4 back-and-forth messages, an endpoint can send two messages
with need-response set to TRUE.

Also, the hop-count in the message-header seems a bit fuzzy conceptually. 
It makes perfect sense to use it in IPv4 to avoid loops of the *same* 
datagram. Here, we are not necessarily talking about the same message being 
ping-panged. To me, it makes more sense to maintain a *local* counter by a 
sender to control the number of responses it want to trigger, not in the 
message-header.

So, unless I missed something important or someone else also wants to 
have the counter, let's keep the current need-response header.

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



From mailnull@www1.ietf.org  Tue Jan 28 14:44:58 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04924
	for <rohc-archive@odin.ietf.org>; Tue, 28 Jan 2003 14:44:58 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0SK64x14002
	for rohc-archive@odin.ietf.org; Tue, 28 Jan 2003 15:06:04 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SK64J13999
	for <rohc-web-archive@optimus.ietf.org>; Tue, 28 Jan 2003 15:06:04 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04907
	for <rohc-web-archive@ietf.org>; Tue, 28 Jan 2003 14:44:26 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SK5jJ13967;
	Tue, 28 Jan 2003 15:05:46 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SK4DJ13908
	for <rohc@optimus.ietf.org>; Tue, 28 Jan 2003 15:04:14 -0500
Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04882
	for <rohc@ietf.org>; Tue, 28 Jan 2003 14:42:36 -0500 (EST)
Received: from venus.office (venus.office [10.1.1.11])
	by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h0SJk7R64868
	for <rohc@ietf.org>; Tue, 28 Jan 2003 20:46:08 +0100 (CET)
	(envelope-from quittek@ccrle.nec.de)
Received: by venus.office (Postfix on SuSE Linux eMail Server 3.0, from userid 30)
	id 230B187110; Tue, 28 Jan 2003 21:52:20 +0100 (CET)
X-Accept-Language: de, en
X-Priority: 3 (Normal)
X-Mailer: SKYRiXgreen_3.1 NGMime_4.2.18
From: "Juergen Quittek" <quittek@ccrle.nec.de>
MIME-Version: 1.0
subject: RE: [rohc] WG last-call for ROHC MIB and related documents
To: rohc@ietf.org
Organization: NEC Europe Ltd.
content-type: text/plain; charset="iso-8859-1"
date:  Tue, 28 Jan 2003 21:52:19 +0100
content-transfer-encoding: 7bit
Message-Id: <20030128205220.230B187110@venus.office>
Content-Transfer-Encoding: 7bit
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Dear ROHCers,

Here are my comments on 
draft-ietf-rohc-terminology-and-examples-01.txt

    Juergen


General:
  The document is very good: it's clear and precise and
  is very useful for understanding ROHC integration into 
  networks.

General:
  The title "Terminology and Examples for MIB Modules and 
  Channel Mappings" addresses MIB modules. But without
  knowing the WG context of this document, a reader would
  not be able to find out what it has to do with MIB modules.
  Therefore, I suggest choosing a title that expresses the
  content of the document rather than the context that led
  to its creation, for example (adapted from Section 8,
  line 1-2:
    "Terminology and Concepts for Use in ROHC Network Integration"

General: 
  Figures are not numbered. Since there are many of them
  in the document, I suggest to number them and give them
  captions.
  
Section 2, Paragraph on "Co-located compressor/decompressor":
  line four talks about "the link" (and so doe the paragraph
  on "Associated compressor/decompressor". However, the term
  'link' is not introduced bevor. Therefore some ambuguity
  remains in the terminology section. Can we clarify this
  by a proper definition of the term 'link'?
  The beginning of section 3.1 has some text coming close
  to a definition of 'link'.

Section 4, first line:
  "For e.g. the purpose of" could perhaps be replaced by
  "For various purposes, such as"

Section 4, line 8:
  I suggest extending the sentence on N compressors and
  M decompressors: replace "are arbitrary numbers." by
  "are arbitrary numbers, and N+M is the number of instances
  present at the IP interface."

Section 7, paragraph 2, line 2:
  "(but normally limited on a per-channel basis)" could
  perhaps be repalced by "(but limited)".
  reasons: 
  - it is always limited, not just normally
  - we are anyway talking on a per-instance basis,
    and we have a one-to-one mapping to channels

Section 7, figure:
  The terms 'HC' and 'HD' used in the figure should be
  either changed or replaced.

Section 7, line 5:
  remove "state" (or alternatively remove "stream" in line 4.
  A packet stream relates to a context, not to a particular
  context state, because the state may change between
  packets.

Section 8, item 5, line 2:
  The sentence is hard to read. I suggest replacing
  "logical layer two channels available" by
  "available logical layer two channels".
-- 
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Wed Jan 29 12:25:11 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23999
	for <rohc-archive@odin.ietf.org>; Wed, 29 Jan 2003 12:25:11 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0THkg609924
	for rohc-archive@odin.ietf.org; Wed, 29 Jan 2003 12:46:42 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0THkgJ09921
	for <rohc-web-archive@optimus.ietf.org>; Wed, 29 Jan 2003 12:46:42 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23992
	for <rohc-web-archive@ietf.org>; Wed, 29 Jan 2003 12:24:39 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0THkOJ09900;
	Wed, 29 Jan 2003 12:46:24 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0THjdJ09869
	for <rohc@optimus.ietf.org>; Wed, 29 Jan 2003 12:45:39 -0500
Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23984
	for <rohc@ietf.org>; Wed, 29 Jan 2003 12:23:36 -0500 (EST)
Received: from venus.office (venus.office [10.1.1.11])
	by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h0THR6R80361;
	Wed, 29 Jan 2003 18:27:06 +0100 (CET)
	(envelope-from Martin.Stiemerling@ccrle.nec.de)
Received: from ccrle.nec.de (stiemerling.office [10.1.1.110])
	by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id 3889210FF9; Wed, 29 Jan 2003 19:33:10 +0100 (CET)
Message-ID: <3E380ED6.90801@ccrle.nec.de>
Date: Wed, 29 Jan 2003 18:26:46 +0100
From: Martin Stiemerling <Martin.Stiemerling@ccrle.nec.de>
Organization: NEC -- Network Labs Europe
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020619
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Lars-Erik Jonsson (EAB)" <Lars-Erik.Jonsson@epl.ericsson.se>
Cc: ROHC WG <rohc@ietf.org>, "Juergen Quittek (E-mail)" <quittek@ccrle.nec.de>
Subject: Re: [rohc] WG last-call for ROHC MIB and related documents
References: <A943FD84BD9ED41193460008C791805003E32507@ESEALNT419.al.sw.ericsson.se>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi Lars-Erik,

(on behave of Juergen)
thank you for the comments, and please see comments inline.

Lars-Erik Jonsson (EAB) wrote:
> Hi all,
> 
> I have reviewed the MIB document and it looks overall very
> good. I have noticed the following that should be addressed:
> 
> - The document should have an IANA Considerations section for the
>   new IANA registrations, both a listing of the new registrations
>   and a "TO BE REMOVED BEFORE PUBLICATION" request text addressed
>   to the IANA).

Correct, this needs to be done.

> 
> - The TOC is a little bit hard to read. It would be clearer by
>   writing e.g. "2.  The SNMP..." instead or "2 The SNMP..."

The current doc is generated by nroff, for the final version we will it 
manually as it is suggested.

> 
> - Last paragraph above section 4.1. should be rewritten to be
>   clearer about which two MIB's are referred to.

Would it be sufficient to replace "these two MIB modules" by "a 
ROHC-UNCOMPRESSED-MIB Module and the ROHC-RTP-MIB Module"?

> 
> - In section 4.1.2, clarify that "feedback for" only applies if
>   the channel is actually transmitting any feedback, either
>   as a dedicated feedback channel or interspersed/piggybacked.

What about adding "(if applicable)" at the end of the 3rd bullet?

> 
> - In section 4.1.4, title of first bullet list, should be
>   "attributes", not "attribute".

Yes.

> 
> - In section 4.1.4, statistics list, fourth bullet, should say
>   "context", not "conrtext".

We will fix this. It is the 5th bullet.

> 
> - In section 4.1.4, statistics list, "mean packet size" bullets
>   (both), should say "packet size" and "compressed packets"
>   instead of "packets size" and "packets".

We agree.

> 
> - In section 4.1.4, statistics list, "mean header size" bullets
>   (both), should say "passing" instead of "in".

OK.

> 
> - On page 11, "rohcChannelType", DESCRIPTION, missing "m" on 
>   "might".

We will fix this.

> 
> - On page 12, "rohcInstanceTable", DESCRIPTION, end of
>   description should read "used for each ROHC instance" instead
>   of "used for ROHC".

We would prefer either just "used", "used by the ROHC instance", "to 
which the ROHC instance is connected", or most precise "used by the ROHC 
instance as the ROHC channel".

> 
> - On page 15, "rohcInstanceLargeCIDs", DESCRIPTION, should say
>   "returns true if the embedded" instead of
>   "returns true, the embedded"

Yes.


> 
> - On page 15, "rohcInstanceMRRU", DESCRIPTION, first sentence
>   has no end, ends with "according to."

"According to" need to be removed.

> 
> - On page 15, "rohcInstanceContextStorageTime", DESCRIPTION,
>   refers to "rohcInstanceContextExpireTime", which does not
>   exist. Should probably say "rohcInstanceContextStorageTime".

OK.

> 
> - On page 16, "rohcInstancePackets", DESCRIPTION, something is
>   missing in the sentence "Counter of passing this instance".

The missing text is "all packets".

> 
> - The most significant problem found is about the ProfileTable,
>   page 17-18. Both compressor and decompressor instances have
>   support for certain profiles, and one should be able to see
>   which profiles are supported and the properties of the
>   various profile implementations, independent of if the
>   instance is a compressor or a decompressor. What should also
>   be readable would be information of which profiles are
>   active, i.e. have been negotiated to be used on an instance.
>   As we have noticed during the last year, RFC 3095 is rather
>   confusing in this regard. So, I would propose the following:
> 
>   1) Change the DESCRIPTION for "rohcProfileTable" to:
>      "This table lists a set of profiles supported by the instance."
> 
>   2) Change the DESCRIPTION for "rohcProfileEntry" to:
>      "An entry describing a particular profile supported by the
>      instance."
> 
>   3) Change the DESCRIPTION for "rohcProfile to:
>      "Identifier of a profile supported. For a listing of
>      possible profile values, see the IANA registry for ROHC
>      profiles [PROFILES]."
> 
>   4) Add the following normative reference:
>      [PROFILES]  "RObust Header Compression (ROHC) Profile 
>                  Identifiers", IANA registry at:
>                  <http://www.iana.org/assignments/rohc-pro-ids>
> 
>   5) Add the following to "RohcProfileEntry":
>        rohcProfileNegotiated   TruthValue
> 
>   6) Add:
>          rohcProfileNegotiated OBJECT-TYPE
>              SYNTAX      TruthValue
>              MAX-ACCESS  read-only
>              STATUS      current
>              DESCRIPTION
>                  "When retrieved, this boolean object returns true
>                   if the profile has been negotiated to be used at
>                   the instance, i.e. is supported also be the
>                   corresponding compressor/decompressor."
>              ::= { rohcProfileEntry 7 }
>                   

We agree on 1 to 6.

> - On page 21, "rohcContextStorageTime", the indentation is
>   wrong (at least 3 spaces more than elsewhere).

We will fix this.

> 
> - On page 33, "rohcContextState", there is a (to me) unknown
>   state listed, "normal(2)". I do not know where this comes

It comes from the UNCOMPRESSED profile. This is a copy and paste mistake.

>   from, but I am pretty sure it should not be there. Make it
>   6 states by removing "normal". This affects both SYNTAX and
>   DESCRIPTION.



> 
> - Section 6, end of 7th line, should say "rows", not "row".

We will fix this typo.

> 
> - Section 8.1, please change the way my name is written in 
>   the second and third references, should be written "L-E.",
>   not "L.-E.". Thanks!

Fine with us.


Martin and Juergen.

> 
> 
> That's all!
> 
> Cheers,
> /L-E
> 
> 
> 
> 
> 
>>-----Original Message-----
>>From: cabo@tzi.org [mailto:cabo@tzi.org]
>>Sent: den 15 januari 2003 17:21
>>To: ROHC WG
>>Subject: [rohc] WG last-call for ROHC MIB and related documents
>>
>>
>>ROHCers,
>>
>>In Atlanta, we said we were going to have another re-spin of the ROHC
>>MIB to include LLA.  This has now been available for nearly a month,
>>and we believe the document has received enough review to issue the WG
>>last-call.  Together with this goes the terminology and examples
>>document as additional explanatory material that at some point is
>>expected to become part of the ROHC draft standard.
>>
>>Therefore, we are now issuing a WG last-call for the following two
>>documents:
>>
>>  draft-ietf-rohc-mib-rtp-05.txt
>>      (for publication as Proposed Standard)
>>
>>  draft-ietf-rohc-terminology-and-examples-01.txt
>>      (for publication as Informational)
>>
>>This is a regular two-week WG last-call.
>>
>>Please direct WG last-call comments to the ROHC mailing list
>>rohc@ietf.org before Wed, 2003-01-29, 18:00 UTC.
>>
>>Gruesse, Carsten
>>
>>_______________________________________________
>>Rohc mailing list
>>Rohc@ietf.org
>>https://www1.ietf.org/mailman/listinfo/rohc
>>
> 
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc



-- 
Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories  Stiemerling@ccrle.nec.de
IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de

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



From mailnull@www1.ietf.org  Wed Jan 29 12:47:52 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24467
	for <rohc-archive@odin.ietf.org>; Wed, 29 Jan 2003 12:47:52 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0TI9OT11566
	for rohc-archive@odin.ietf.org; Wed, 29 Jan 2003 13:09:24 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TI9OJ11563
	for <rohc-web-archive@optimus.ietf.org>; Wed, 29 Jan 2003 13:09:24 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24464
	for <rohc-web-archive@ietf.org>; Wed, 29 Jan 2003 12:47:21 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TI9AJ11553;
	Wed, 29 Jan 2003 13:09:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TI81J11519
	for <rohc@optimus.ietf.org>; Wed, 29 Jan 2003 13:08:01 -0500
Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24445
	for <rohc@ietf.org>; Wed, 29 Jan 2003 12:45:57 -0500 (EST)
Received: from venus.office (venus.office [10.1.1.11])
	by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h0THnSR80592;
	Wed, 29 Jan 2003 18:49:28 +0100 (CET)
	(envelope-from Martin.Stiemerling@ccrle.nec.de)
Received: from ccrle.nec.de (stiemerling.office [10.1.1.110])
	by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id 4CD5CAD55; Wed, 29 Jan 2003 19:55:32 +0100 (CET)
Message-ID: <3E381414.8030007@ccrle.nec.de>
Date: Wed, 29 Jan 2003 18:49:08 +0100
From: Martin Stiemerling <Martin.Stiemerling@ccrle.nec.de>
Organization: NEC -- Network Labs Europe
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020619
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Carsten Bormann <cabo@tzi.org>
Cc: ROHC WG <rohc@ietf.org>
Subject: Re: [rohc] WG last-call for ROHC MIB and related documents
References: <m2lm1mtmdw.fsf@marie.local.>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi,

comments on draft-ietf-rohc-terminology-and-examples-01.txt by Juergen 
and me:

General:
The document is very good, it is clear and precise and it is very useful 
for understanding ROHC integration into network.

General:
The Title "Terminology and Examples for MIB Modules and Channel 
Mappings" addresses MIB Modules. But without knwoning the WG context of 
this document, the reader would not be able to find out what it has to 
do with MIB Modules. Therefore, we suggest choosing the Title that 
expresses the content of the document, rather than the context that led 
to its creation, e.g. (addapted from section 8, line 1-2):
"Terminology and Concept for Use in ROHC Network Integration".

General:
Figures are not numbered. Since there are many of them in the document, 
we suggest to number them and give them captions.

Section 2, Paragraph on "Co-located compressor/de-compressor":
Line 4  talks about "the link" (and so does the paragraph on "Associated 
compressor/de-compressor"). However, the term "link" is not introduced. 
Therefore, some ambiquity remains in the terminology section. Can we 
clarfiy this by a proper definition of the term "link"? The beginning of 
section 3.1 has some text coming close to a definition of "link".

Section 4, line 1:
  "For e.g. the purpose of " could perhaps be replaced by "For various 
purposes, such as".

Section 4, line 8:
  We suggest expanding the sentence on N compressors and M 
decompressors: Replace "are arbitrary numbers." by " are arbitrary 
numbers, and N+M is the number of instances present at the IP interface."

Section 7, paragraph 2, line 2:
"(but normally limitted on per Channel basis)" could perhaps be replaced 
by "(but limitted)".
Reasons:
- it is always limited, not just normally
- we are anyway talking on a instance basis, and we have a one-to-one 
mapping to channels.

Section 7, figures:
The terms "HC" and "HD" used in the figures should be either changed or 
explained.

Section 7, line 5:
Remove "state" (or alternatively remove "stream" in line 4). A packet 
stream relates to a context, not to a particular context state, because 
the state may change between packets.

Section 8, item 5, line 2:
The sentences is hard to read. We suggest replacing "logical layer two 
channels available" by "available logical layer two channels".

Juergen and Martin



Carsten Bormann wrote:
> ROHCers,
> 
> In Atlanta, we said we were going to have another re-spin of the ROHC
> MIB to include LLA.  This has now been available for nearly a month,
> and we believe the document has received enough review to issue the WG
> last-call.  Together with this goes the terminology and examples
> document as additional explanatory material that at some point is
> expected to become part of the ROHC draft standard.
> 
> Therefore, we are now issuing a WG last-call for the following two
> documents:
> 
>   draft-ietf-rohc-mib-rtp-05.txt
>       (for publication as Proposed Standard)
> 
>   draft-ietf-rohc-terminology-and-examples-01.txt
>       (for publication as Informational)
> 
> This is a regular two-week WG last-call.
> 
> Please direct WG last-call comments to the ROHC mailing list
> rohc@ietf.org before Wed, 2003-01-29, 18:00 UTC.
> 
> Gruesse, Carsten
> 
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc



-- 
Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories  Stiemerling@ccrle.nec.de
IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de

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



From mailnull@www1.ietf.org  Thu Jan 30 01:37:51 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10395
	for <rohc-archive@odin.ietf.org>; Thu, 30 Jan 2003 01:37:51 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0TNS0100369
	for rohc-archive@odin.ietf.org; Wed, 29 Jan 2003 18:28:00 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TNRxJ00366
	for <rohc-web-archive@optimus.ietf.org>; Wed, 29 Jan 2003 18:27:59 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03029
	for <rohc-web-archive@ietf.org>; Wed, 29 Jan 2003 18:05:50 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TNOtJ32690;
	Wed, 29 Jan 2003 18:24:57 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TNNoJ32624
	for <rohc@optimus.ietf.org>; Wed, 29 Jan 2003 18:23:50 -0500
Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02874
	for <rohc@ietf.org>; Wed, 29 Jan 2003 18:01:41 -0500 (EST)
From: EXT-Narendra.Chaparala@nokia.com
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0TN50210196
	for <rohc@ietf.org>; Wed, 29 Jan 2003 17:05:11 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T60174ea57aac12f257071@davir04nok.americas.nokia.com> for <rohc@ietf.org>;
 Wed, 29 Jan 2003 17:04:50 -0600
Received: from daebe008.NOE.Nokia.com ([172.18.242.238]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Wed, 29 Jan 2003 17:04:19 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Wed, 29 Jan 2003 17:04:18 -0600
Message-ID: <7CA3477F476D7F4FB82F02960B79CEBD0231D095@daebe008.americas.nokia.com>
Thread-Topic: SIP/SDP dictionary Version 5
Thread-Index: AcLH6s4mgEuOGhXDQuiDJ7KT57s2RQ==
To: <rohc@ietf.org>
X-OriginalArrivalTime: 29 Jan 2003 23:04:19.0232 (UTC) FILETIME=[C0E54200:01C2C7EA]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0TNNoJ32625
Subject: [rohc] SIP/SDP dictionary Version 5
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Hi,
    I'm having different state identifier (hash) value for the SIP/SDP static dictionary taken from draft-ietf-sipping-sigcomp-sip-dictionary-05.txt draft. I want to know if anyone encountered different hash value when a state of the static dictinary is created. 

The state identifier value for my calculation = 0x 22 ee d9 6f 22 2e 


thank you,
Narendra
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Thu Jan 30 01:38:54 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10427
	for <rohc-archive@odin.ietf.org>; Thu, 30 Jan 2003 01:38:51 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0U00aw02291
	for rohc-archive@odin.ietf.org; Wed, 29 Jan 2003 19:00:36 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U00aJ02288
	for <rohc-web-archive@optimus.ietf.org>; Wed, 29 Jan 2003 19:00:36 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03529
	for <rohc-web-archive@ietf.org>; Wed, 29 Jan 2003 18:38:26 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U00MJ02280;
	Wed, 29 Jan 2003 19:00:22 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TNxKJ02214
	for <rohc@optimus.ietf.org>; Wed, 29 Jan 2003 18:59:20 -0500
Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03511
	for <rohc@ietf.org>; Wed, 29 Jan 2003 18:37:09 -0500 (EST)
Received: from venus.office (venus.office [10.1.1.11])
	by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h0TNe9R84526;
	Thu, 30 Jan 2003 00:40:09 +0100 (CET)
	(envelope-from quittek@ccrle.nec.de)
Received: from [10.1.1.26] (dial02.office [10.1.1.26])
	by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id A9EEB8718F; Thu, 30 Jan 2003 01:46:08 +0100 (CET)
Date: Thu, 30 Jan 2003 00:41:26 +0100
From: Juergen Quittek <quittek@ccrle.nec.de>
To: Carsten Bormann <cabo@tzi.org>, ROHC WG <rohc@ietf.org>
Subject: Re: [rohc] WG last-call for ROHC MIB and related documents
Message-ID: <3407229.1043887285@[10.1.1.26]>
In-Reply-To: <m2lm1mtmdw.fsf@marie.local.>
References:  <m2lm1mtmdw.fsf@marie.local.>
X-Mailer: Mulberry/2.1.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Dear ROHCers,

A little bit after the deadline, I have two more comments on
draft-ietf-rohc-mib-rtp-05.txt:

General:
  The boilerplate for documents specifying MIB modules
  has changed recently. We should try to update the document
  accordingly. This will include changes in the introduction
  (Section 1), the MIB definition itself (Section 5), and
  the Referneces (Section 8).

Section 8:
  The RFC editor suggests having two individual top level
  sections for normative and informative references
  instead of having them as subsections in a top level
  section on references.
  I suggest to adapt to this scheme transforming
  "8.Referneces
   8.1 Normative Referneces
   8.2 Informative References"
  into
  "8 Normative Referneces
   9 Informative References"

        Juergen
-- 
Juergen Quittek        quittek@ccrle.nec.de        Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.ccrle.nec.de


-- Carsten Bormann wrote on 15 January 2003 17:20 +0100:

> ROHCers,
>
> In Atlanta, we said we were going to have another re-spin of the ROHC
> MIB to include LLA.  This has now been available for nearly a month,
> and we believe the document has received enough review to issue the WG
> last-call.  Together with this goes the terminology and examples
> document as additional explanatory material that at some point is
> expected to become part of the ROHC draft standard.
>
> Therefore, we are now issuing a WG last-call for the following two
> documents:
>
>   draft-ietf-rohc-mib-rtp-05.txt
>       (for publication as Proposed Standard)
>
>   draft-ietf-rohc-terminology-and-examples-01.txt
>       (for publication as Informational)
>
> This is a regular two-week WG last-call.
>
> Please direct WG last-call comments to the ROHC mailing list
> rohc@ietf.org before Wed, 2003-01-29, 18:00 UTC.
>
> Gruesse, Carsten
>
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc


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



From mailnull@www1.ietf.org  Thu Jan 30 01:39:26 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10458
	for <rohc-archive@odin.ietf.org>; Thu, 30 Jan 2003 01:39:24 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0U05EP02445
	for rohc-archive@odin.ietf.org; Wed, 29 Jan 2003 19:05:14 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U05EJ02442
	for <rohc-web-archive@optimus.ietf.org>; Wed, 29 Jan 2003 19:05:14 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03572
	for <rohc-web-archive@ietf.org>; Wed, 29 Jan 2003 18:43:04 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U053J02432;
	Wed, 29 Jan 2003 19:05:03 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U04LJ02394
	for <rohc@optimus.ietf.org>; Wed, 29 Jan 2003 19:04:21 -0500
Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03566
	for <rohc@ietf.org>; Wed, 29 Jan 2003 18:42:11 -0500 (EST)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0TNjcp12575;
	Wed, 29 Jan 2003 17:45:39 -0600 (CST)
Received: from zrc2c009.us.nortel.com ([47.103.120.49]) by zrc2c011.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id DXWL9A8Y; Wed, 29 Jan 2003 17:45:38 -0600
Received: from iqmail.net (chowdury-2.us.nortel.com [47.103.84.30]) by zrc2c009.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id DRS1XFDN; Wed, 29 Jan 2003 17:45:38 -0600
Message-ID: <3E38667E.2030104@iqmail.net>
Date: Wed, 29 Jan 2003 17:40:46 -0600
X-Sybari-Space: 00000000 00000000 00000000
From: Kuntal Chowdhury <kuntal@iqmail.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "West, Mark (ITN)" <mark.a.west@roke.co.uk>
CC: rohc@ietf.org
Subject: Re: [rohc] comment on ROHC-TCP
References: <76C92FBBFB58D411AE760090271ED41805DF6631@rsys002a.roke.co.uk>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi Mark,
when I re-read the text in section 3.3 I notice that it briefly points out the 
distinction between HTTP1.0 and HTTP1.1. I agree with you that for persistence 
to work, the server must support HTTP1.1 and it must be willing to keep the TCP 
connection open for multiple HTTP transactions. Actually this behavior of the 
application is controlled by the "Connection header".
e.g.:
Connection: Keep-Alive.
Connection: Close.

After receiving the first Connection header, the application in the MS pretty 
much knows whether the TCP socket is a persistent one or not. this knowledge can 
be leveraged in some way to distinguish which TCP connection is really short 
lived and which ones are not.

Thoughts?

-Kuntal



West, Mark (ITN) wrote:
> Hi Kuntal,
> 
> Thanks for this comment (which relates to the behaviour as well as to the interpretation of this in the main compression draft).  I've got a bunch of updates for the TCP behavior (thanks to a number of very useful comments from various people) -- and this has reminded me to post a proposed update!
> 
> Broadly speaking, I agree with your distinction.  However, it raises a couple of interesting points.  For example, it is perhaps worth pointing out that 'short-lived' doesn't necessarily relate to the duration for which the connection is open, but rather the volume of data that is transferred.  So, for example, the FTP control connection could be regarded as short-lived (at leat compared with the data connection)?!  (I don't know if that necessarily makes an isolated short-lived connection less rare, though...)
> 
> In principle, your comments about HTTP/1.0 vs HTTP/1.1 make sense.  But if I understand it correctly, the benefits of HTTP/1.1 rely upon agreement between the browser and server and the appropriate configuration of both (certainly of the server)?  You can certainly still have multiple connections to the server with HTTP/1.1.  I'd certainly appreciate input on this application-layer behaviour, as it impacts on the transport.
> 
> Anyway, I'll propose some updated (behaviour) text in the next few days.
> 
> Cheers,
> 
> Mark.
> 
> 
> 
> 
>>-----Original Message-----
>>From: Kuntal Chowdhury [mailto:kuntal@iqmail.net]
>>Sent: 21 January 2003 20:38
>>To: rohc@ietf.org
>>Subject: [rohc] comment on ROHC-TCP
>>
>>
>>Hello folks,
>>I think we need to separate the issues between a single short 
>>lived TCP 
>>connection (rare event) from multiple (near-)simultaneous short lived
>>TCP connections. The reason being, the scenario of single short lived 
>>TCP connection applies to both HTTP1.0 and 1.1, however the 
>>scenario of 
>>multiple short lived (near-)simultaneous TCP connections may be a 
>>problem with HTTP1.0 only (HTTP1.1 solves the problem with 
>>persistence 
>>and pipelining as default behavior). Therefore I suggest, we split 
>>section 3.3 to discuss single short lived and multiple 
>>(near-)simultaneous short lived TCP connections separately.
>>
>>Thoughts?
>>
>>-Kuntal
>>
>>_______________________________________________
>>Rohc mailing list
>>Rohc@ietf.org
>>https://www1.ietf.org/mailman/listinfo/rohc
>>
>>
>>
>>------------------------------------------------------------------------
>>
>>Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell, 
>>Berkshire. RG12 8FZ
>>
>>The information contained in this e-mail and any attachments is confidential to Roke 
>>
>>
>>Manor Research Ltd and must not be passed to any third party without permission. This 
>>
>>
>>communication is for information only and shall not create or change any contractual 
>>
>>
>>relationship.
> 


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



From mailnull@www1.ietf.org  Thu Jan 30 07:59:16 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26295
	for <rohc-archive@odin.ietf.org>; Thu, 30 Jan 2003 07:59:16 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0UDLBJ30338
	for rohc-archive@odin.ietf.org; Thu, 30 Jan 2003 08:21:11 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UDLBJ30335
	for <rohc-web-archive@optimus.ietf.org>; Thu, 30 Jan 2003 08:21:11 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26268
	for <rohc-web-archive@ietf.org>; Thu, 30 Jan 2003 07:58:45 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UDKrJ30318;
	Thu, 30 Jan 2003 08:20:54 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UDIBJ30165
	for <rohc@optimus.ietf.org>; Thu, 30 Jan 2003 08:18:11 -0500
Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26151
	for <rohc@ietf.org>; Thu, 30 Jan 2003 07:55:42 -0500 (EST)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0UCxCKV007322;
	Thu, 30 Jan 2003 13:59:12 +0100 (MET)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <DY5SC535>; Thu, 30 Jan 2003 13:59:12 +0100
Message-ID: <F005CD411D18D3119C8F00508B0874800A1446BE@ehubunt100.eth.ericsson.se>
From: "Lajos Zaccomer (ETH)" <Lajos.Zaccomer@eth.ericsson.se>
To: "'rohc@ietf.org'" <rohc@ietf.org>
Cc: "'zhigang.c.liu@nokia.com'" <zhigang.c.liu@nokia.com>,
        "'Adam Roach'"
	 <adam@dynamicsoft.com>,
        "'Surtees, Abigail'"
	 <abigail.surtees@roke.co.uk>
Date: Thu, 30 Jan 2003 13:57:27 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-2"
Subject: [rohc] DAP issues
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi,

The discussions on DAP should be ended this week as the SIPit is very close. All the participants that intend using DAP should accept a last version that should be available at latest on Monday morning. The accepted version should be used by the participants of SIPit.

I have the following modification and extention proposals:

* parameterization of compartment create:
this line is processed only if line-6 brings CREATE
line-6a = "state-memory-size" ":" *DIGIT CRLF
if there is no parameter, the application on its own may choose a state memory size
(it might be line-7 or whatever with shifting the other lines)

* need-response should have values: ("ANY" / "PREV" / "NO")
	- ANY: implementation choice
	- PREV: send back the previously uncompressed message of the compartment
		(This is very useful for testing if the message was decompressed correctly, as the other endpoint does not know what I sent.)
	- NO: need no response

* the header should not be arbitrary in case of a response. It should not be allowed to ask for a response in this case. It is most favourable that the message flow may be  entirely controlled by one of the endpoints!

* There should be another line to start/stop the dispatcher. Reason: there are tests even amongst the torture testst that use non-default values, and it is favourable to test all possible situations.

line-x = "dispatcher-op" ":" ( "START" / "STOP" );
line-y = "dispatcher-params" ":" *DIGIT ":" *DIGIT ":" *DIGIT
(may be inserted somewhere before the body line)
The three parameters - each of which are optional - are the cpb, dms and sms values for the dispatcher, respectively. If any of them is not specified or invalid, the application may choose a valid value instead.

With these modifications a whole series of tests may be run automatically.

Please, consider the above issues and comment them!

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



From mailnull@www1.ietf.org  Thu Jan 30 08:30:41 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27495
	for <rohc-archive@odin.ietf.org>; Thu, 30 Jan 2003 08:30:41 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0UDqbE32519
	for rohc-archive@odin.ietf.org; Thu, 30 Jan 2003 08:52:37 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UDqbJ32516
	for <rohc-web-archive@optimus.ietf.org>; Thu, 30 Jan 2003 08:52:37 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27471
	for <rohc-web-archive@ietf.org>; Thu, 30 Jan 2003 08:30:09 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UDqCJ32476;
	Thu, 30 Jan 2003 08:52:12 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UDpqJ32457
	for <rohc@optimus.ietf.org>; Thu, 30 Jan 2003 08:51:52 -0500
Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27399
	for <rohc@ietf.org>; Thu, 30 Jan 2003 08:29:25 -0500 (EST)
Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0UDWuAv008376;
	Thu, 30 Jan 2003 14:32:56 +0100 (MET)
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <DW0B7VG8>; Thu, 30 Jan 2003 14:32:56 +0100
Message-ID: <A943FD84BD9ED41193460008C791805003E32537@ESEALNT419.al.sw.ericsson.se>
From: "Lars-Erik Jonsson (EAB)" <Lars-Erik.Jonsson@epl.ericsson.se>
To: "'Juergen Quittek'" <quittek@ccrle.nec.de>, rohc@ietf.org
Subject: RE: [rohc] WG last-call for ROHC MIB and related documents
Date: Thu, 30 Jan 2003 14:28:46 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Juergen and others,

Thanks for the review, all comments will be addressed in an update. 
However, this comment is a tricky one:

> General:
>   The title "Terminology and Examples for MIB Modules and 
>   Channel Mappings" addresses MIB modules. But without
>   knowing the WG context of this document, a reader would
>   not be able to find out what it has to do with MIB modules.
>   Therefore, I suggest choosing a title that expresses the
>   content of the document rather than the context that led
>   to its creation, for example (adapted from Section 8,
>   line 1-2:
>     "Terminology and Concepts for Use in ROHC Network Integration"

Carsten and I have discussed the title of this document several
times, and obviously it is hard to find a proper title. I think
the current title is ok, although I agree that the presence of
"MIB" in it might make it look relevant only for MIB's. I also
think the title proposed above, or variants of it, would be ok.
I do not have any strong opinions about this.

Any thoughts from others?

Rgds,
/L-E
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Thu Jan 30 12:52:23 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05473
	for <rohc-archive@odin.ietf.org>; Thu, 30 Jan 2003 12:52:22 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0UHtSQ18481
	for rohc-archive@odin.ietf.org; Thu, 30 Jan 2003 12:55:28 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UHtSJ18478
	for <rohc-web-archive@optimus.ietf.org>; Thu, 30 Jan 2003 12:55:28 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05450
	for <rohc-web-archive@ietf.org>; Thu, 30 Jan 2003 12:51:51 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UHt6J18465;
	Thu, 30 Jan 2003 12:55:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UHrfJ18421
	for <rohc@optimus.ietf.org>; Thu, 30 Jan 2003 12:53:41 -0500
Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05430
	for <rohc@ietf.org>; Thu, 30 Jan 2003 12:50:04 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <CN3DAH5N>; Thu, 30 Jan 2003 17:53:34 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED41804B88609@rsys002a.roke.co.uk>
From: "Surtees, Abigail" <abigail.surtees@roke.co.uk>
To: "'Lajos Zaccomer (ETH)'" <Lajos.Zaccomer@eth.ericsson.se>,
        "'rohc@ietf.org'" <rohc@ietf.org>
Cc: "'zhigang.c.liu@nokia.com'" <zhigang.c.liu@nokia.com>,
        "'Adam Roach'"
	 <adam@dynamicsoft.com>
Date: Thu, 30 Jan 2003 17:53:30 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-2"
Subject: [rohc] RE: DAP issues
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi all,

>The discussions on DAP should be ended this week as the SIPit 
>is very close. All the participants that intend using DAP 
>should accept a last version that should be available at 
>latest on Monday morning. The accepted version should be used 
>by the participants of SIPit.

This sounds reasonable to me.

>
>I have the following modification and extention proposals:
>
<snip - moved to bottom>
>
>* need-response should have values: ("ANY" / "PREV" / "NO")
>	- ANY: implementation choice
>	- PREV: send back the previously uncompressed message 
>of the compartment
>		(This is very useful for testing if the message 
>was decompressed correctly, as the other endpoint does not 
>know what I sent.)
>	- NO: need no response
>
I think it is still defined in DAP to echo the received message back to the sender, uncompressed, so there isn't any need to recompress it and send it back for checking purposes.  Consequently the TRUE/FALSE corresponds to ANY/NO and is sufficient for our testing at the moment.  (ANY could be equivalent to PREV, depending upon the configuration of the decompressor)

>* the header should not be arbitrary in case of a response. It 
>should not be allowed to ask for a response in this case. It 
>is most favourable that the message flow may be  entirely 
>controlled by one of the endpoints!
>
I think that it makes sense for the receiver not to ask for a response so that the sending end is in control of the flow but I don't think it needs to be specified in DAP.  The receiver can just never set the response field to TRUE and the sender should ignore this field.

>* parameterization of compartment create:
>this line is processed only if line-6 brings CREATE
>line-6a = "state-memory-size" ":" *DIGIT CRLF
>if there is no parameter, the application on its own may 
>choose a state memory size
>(it might be line-7 or whatever with shifting the other lines)
>
>* There should be another line to start/stop the dispatcher. 
>Reason: there are tests even amongst the torture testst that 
>use non-default values, and it is favourable to test all 
>possible situations.
>
I believe that there is only one torture test now that doesn't run in 2K of memory and that it can be modified to run in 2K.

>line-x = "dispatcher-op" ":" ( "START" / "STOP" );
>line-y = "dispatcher-params" ":" *DIGIT ":" *DIGIT ":" *DIGIT
>(may be inserted somewhere before the body line)
>The three parameters - each of which are optional - are the 
>cpb, dms and sms values for the dispatcher, respectively. If 
>any of them is not specified or invalid, the application may 
>choose a valid value instead.
>

I think that in both these cases there may be some merit in defining them in the future but that for the moment we have sufficient for a first face-to-face testing event.  

As it is defined a SigComp decompressor would not expect to have to change these parameters on the fly so to do it would bring extra implementation.  It would also need more definition than this due to the fact that some of these are endpoint actions rather than compartment actions.  If an endpoint were connected to 2 peers and one sent a dispatcher-op : STOP message, what would happen to the connection to the other peer?...

I think (correct me if I'm wrong) that for the first testing event we want a simple protocol that we can ascertain quickly is doing what we expect so that we can concentrate on the SigComp testing itself.  Then if we want to do more testing or possibly remote testing we could define some of these actions, later.

Best regards,

Abbie,


>With these modifications a whole series of tests may be run 
>automatically.
>
>Please, consider the above issues and comment them!
>
>BR/Zacco
>
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Thu Jan 30 13:23:38 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06060
	for <rohc-archive@odin.ietf.org>; Thu, 30 Jan 2003 13:23:38 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0UIQiN20109
	for rohc-archive@odin.ietf.org; Thu, 30 Jan 2003 13:26:44 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UIQiJ20106
	for <rohc-web-archive@optimus.ietf.org>; Thu, 30 Jan 2003 13:26:44 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06056
	for <rohc-web-archive@ietf.org>; Thu, 30 Jan 2003 13:23:06 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UIQMJ20094;
	Thu, 30 Jan 2003 13:26:22 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UIPWJ20067
	for <rohc@optimus.ietf.org>; Thu, 30 Jan 2003 13:25:32 -0500
Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06042
	for <rohc@ietf.org>; Thu, 30 Jan 2003 13:21:52 -0500 (EST)
From: zhigang.c.liu@nokia.com
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0UIPP206481
	for <rohc@ietf.org>; Thu, 30 Jan 2003 12:25:25 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T601b750f57ac12f257071@davir04nok.americas.nokia.com>;
 Thu, 30 Jan 2003 12:25:16 -0600
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Thu, 30 Jan 2003 12:24:33 -0600
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-2"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
Date: Thu, 30 Jan 2003 12:24:32 -0600
Message-ID: <DE0842B293FC4847992F9EDF8D72E1ED24A777@daebe005.americas.nokia.com>
Thread-Topic: DAP issues
Thread-Index: AcLIiJaN4EWfofhVTiqVmHuWSQUBrwAARRbg
To: <abigail.surtees@roke.co.uk>, <Lajos.Zaccomer@eth.ericsson.se>,
        <rohc@ietf.org>
Cc: <adam@dynamicsoft.com>
X-OriginalArrivalTime: 30 Jan 2003 18:24:33.0795 (UTC) FILETIME=[D6689530:01C2C88C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0UIPWJ20068
Subject: [rohc] RE: DAP issues
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Hi,

I agree pretty much with Abbie, especially the technical reasons. Let's keep this simple for the first sigcomp interop (we're running out of time). We will have time to discuss the next one after this.

As Zacco proposed, please send any other comments by end of this week. I'll be on vacation tomorrow (Friday) and but be back on Monday. Will see if any other issues pop up (I hope not).

BR,
Zhigang

> -----Original Message-----
> From: ext Surtees, Abigail [mailto:abigail.surtees@roke.co.uk]
> Sent: January 30, 2003 11:54 AM
> To: 'Lajos Zaccomer (ETH)'; 'rohc@ietf.org'
> Cc: Liu Zhigang.C (NRC/Dallas); 'Adam Roach'
> Subject: RE: DAP issues
> 
> 
> Hi all,
> 
> >The discussions on DAP should be ended this week as the SIPit 
> >is very close. All the participants that intend using DAP 
> >should accept a last version that should be available at 
> >latest on Monday morning. The accepted version should be used 
> >by the participants of SIPit.
> 
> This sounds reasonable to me.
> 
> >
> >I have the following modification and extention proposals:
> >
> <snip - moved to bottom>
> >
> >* need-response should have values: ("ANY" / "PREV" / "NO")
> >	- ANY: implementation choice
> >	- PREV: send back the previously uncompressed message 
> >of the compartment
> >		(This is very useful for testing if the message 
> >was decompressed correctly, as the other endpoint does not 
> >know what I sent.)
> >	- NO: need no response
> >
> I think it is still defined in DAP to echo the received 
> message back to the sender, uncompressed, so there isn't any 
> need to recompress it and send it back for checking purposes. 
>  Consequently the TRUE/FALSE corresponds to ANY/NO and is 
> sufficient for our testing at the moment.  (ANY could be 
> equivalent to PREV, depending upon the configuration of the 
> decompressor)
> 
> >* the header should not be arbitrary in case of a response. It 
> >should not be allowed to ask for a response in this case. It 
> >is most favourable that the message flow may be  entirely 
> >controlled by one of the endpoints!
> >
> I think that it makes sense for the receiver not to ask for a 
> response so that the sending end is in control of the flow 
> but I don't think it needs to be specified in DAP.  The 
> receiver can just never set the response field to TRUE and 
> the sender should ignore this field.
> 
> >* parameterization of compartment create:
> >this line is processed only if line-6 brings CREATE
> >line-6a = "state-memory-size" ":" *DIGIT CRLF
> >if there is no parameter, the application on its own may 
> >choose a state memory size
> >(it might be line-7 or whatever with shifting the other lines)
> >
> >* There should be another line to start/stop the dispatcher. 
> >Reason: there are tests even amongst the torture testst that 
> >use non-default values, and it is favourable to test all 
> >possible situations.
> >
> I believe that there is only one torture test now that 
> doesn't run in 2K of memory and that it can be modified to run in 2K.
> 
> >line-x = "dispatcher-op" ":" ( "START" / "STOP" );
> >line-y = "dispatcher-params" ":" *DIGIT ":" *DIGIT ":" *DIGIT
> >(may be inserted somewhere before the body line)
> >The three parameters - each of which are optional - are the 
> >cpb, dms and sms values for the dispatcher, respectively. If 
> >any of them is not specified or invalid, the application may 
> >choose a valid value instead.
> >
> 
> I think that in both these cases there may be some merit in 
> defining them in the future but that for the moment we have 
> sufficient for a first face-to-face testing event.  
> 
> As it is defined a SigComp decompressor would not expect to 
> have to change these parameters on the fly so to do it would 
> bring extra implementation.  It would also need more 
> definition than this due to the fact that some of these are 
> endpoint actions rather than compartment actions.  If an 
> endpoint were connected to 2 peers and one sent a 
> dispatcher-op : STOP message, what would happen to the 
> connection to the other peer?...
> 
> I think (correct me if I'm wrong) that for the first testing 
> event we want a simple protocol that we can ascertain quickly 
> is doing what we expect so that we can concentrate on the 
> SigComp testing itself.  Then if we want to do more testing 
> or possibly remote testing we could define some of these 
> actions, later.
> 
> Best regards,
> 
> Abbie,
> 
> 
> >With these modifications a whole series of tests may be run 
> >automatically.
> >
> >Please, consider the above issues and comment them!
> >
> >BR/Zacco
> >
> 
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Fri Jan 31 07:10:10 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04317
	for <rohc-archive@odin.ietf.org>; Fri, 31 Jan 2003 07:10:10 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0VCDcB21656
	for rohc-archive@odin.ietf.org; Fri, 31 Jan 2003 07:13:38 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VCDcJ21653
	for <rohc-web-archive@optimus.ietf.org>; Fri, 31 Jan 2003 07:13:38 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04306
	for <rohc-web-archive@ietf.org>; Fri, 31 Jan 2003 07:09:33 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VCDFJ21636;
	Fri, 31 Jan 2003 07:13:15 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VCCGJ21605
	for <rohc@optimus.ietf.org>; Fri, 31 Jan 2003 07:12:16 -0500
Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04301
	for <rohc@ietf.org>; Fri, 31 Jan 2003 07:08:16 -0500 (EST)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0VCBlAw005512;
	Fri, 31 Jan 2003 13:11:48 +0100 (MET)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <DY5SL1BB>; Fri, 31 Jan 2003 13:11:47 +0100
Message-ID: <F005CD411D18D3119C8F00508B0874800A1446CD@ehubunt100.eth.ericsson.se>
From: "Lajos Zaccomer (ETH)" <Lajos.Zaccomer@eth.ericsson.se>
To: "'rohc@ietf.org'" <rohc@ietf.org>
Cc: "'Surtees, Abigail'" <abigail.surtees@roke.co.uk>
Date: Fri, 31 Jan 2003 13:06:42 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-2"
Subject: [rohc] RE: DAP issues
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi,

If it is the decompressed message that should be sent back uncompressed then it's all right. It needs a little clarification in the doc. I e.g. thought it was the SigComp message that should be sent back.
I agree, let's keep it simple. That is why even the least possibility of having dead lock should be removed! If we all agree that a response should not be asked in case of a response, let's have it specified in the doc! Including the received header also unnecessarily complicates the DAP logic. I think the header should not be included! Is there a special reason to have it? If not let's keep it simple!
It is VERY IMPORTANT regarding the very short available time that there will be no interoperability problems with DAP. It should be STRICT with NO MAY in the specification, only MUST!

BR/Zacco



-----Original Message-----
From: Surtees, Abigail [mailto:abigail.surtees@roke.co.uk]
Sent: Thursday, January 30, 2003 6:54 PM
To: 'Lajos Zaccomer (ETH)'; 'rohc@ietf.org'
Cc: 'zhigang.c.liu@nokia.com'; 'Adam Roach'
Subject: RE: DAP issues


Hi all,

>The discussions on DAP should be ended this week as the SIPit 
>is very close. All the participants that intend using DAP 
>should accept a last version that should be available at 
>latest on Monday morning. The accepted version should be used 
>by the participants of SIPit.

This sounds reasonable to me.

>
>I have the following modification and extention proposals:
>
<snip - moved to bottom>
>
>* need-response should have values: ("ANY" / "PREV" / "NO")
>	- ANY: implementation choice
>	- PREV: send back the previously uncompressed message 
>of the compartment
>		(This is very useful for testing if the message 
>was decompressed correctly, as the other endpoint does not 
>know what I sent.)
>	- NO: need no response
>
I think it is still defined in DAP to echo the received message back to the sender, uncompressed, so there isn't any need to recompress it and send it back for checking purposes.  Consequently the TRUE/FALSE corresponds to ANY/NO and is sufficient for our testing at the moment.  (ANY could be equivalent to PREV, depending upon the configuration of the decompressor)

>* the header should not be arbitrary in case of a response. It 
>should not be allowed to ask for a response in this case. It 
>is most favourable that the message flow may be  entirely 
>controlled by one of the endpoints!
>
I think that it makes sense for the receiver not to ask for a response so that the sending end is in control of the flow but I don't think it needs to be specified in DAP.  The receiver can just never set the response field to TRUE and the sender should ignore this field.

>* parameterization of compartment create:
>this line is processed only if line-6 brings CREATE
>line-6a = "state-memory-size" ":" *DIGIT CRLF
>if there is no parameter, the application on its own may 
>choose a state memory size
>(it might be line-7 or whatever with shifting the other lines)
>
>* There should be another line to start/stop the dispatcher. 
>Reason: there are tests even amongst the torture testst that 
>use non-default values, and it is favourable to test all 
>possible situations.
>
I believe that there is only one torture test now that doesn't run in 2K of memory and that it can be modified to run in 2K.

>line-x = "dispatcher-op" ":" ( "START" / "STOP" );
>line-y = "dispatcher-params" ":" *DIGIT ":" *DIGIT ":" *DIGIT
>(may be inserted somewhere before the body line)
>The three parameters - each of which are optional - are the 
>cpb, dms and sms values for the dispatcher, respectively. If 
>any of them is not specified or invalid, the application may 
>choose a valid value instead.
>

I think that in both these cases there may be some merit in defining them in the future but that for the moment we have sufficient for a first face-to-face testing event.  

As it is defined a SigComp decompressor would not expect to have to change these parameters on the fly so to do it would bring extra implementation.  It would also need more definition than this due to the fact that some of these are endpoint actions rather than compartment actions.  If an endpoint were connected to 2 peers and one sent a dispatcher-op : STOP message, what would happen to the connection to the other peer?...

I think (correct me if I'm wrong) that for the first testing event we want a simple protocol that we can ascertain quickly is doing what we expect so that we can concentrate on the SigComp testing itself.  Then if we want to do more testing or possibly remote testing we could define some of these actions, later.

Best regards,

Abbie,


>With these modifications a whole series of tests may be run 
>automatically.
>
>Please, consider the above issues and comment them!
>
>BR/Zacco
>
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From mailnull@www1.ietf.org  Fri Jan 31 08:42:04 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06176
	for <rohc-archive@odin.ietf.org>; Fri, 31 Jan 2003 08:42:04 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0VDjY926729
	for rohc-archive@odin.ietf.org; Fri, 31 Jan 2003 08:45:34 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VDjYJ26726
	for <rohc-web-archive@optimus.ietf.org>; Fri, 31 Jan 2003 08:45:34 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06163
	for <rohc-web-archive@ietf.org>; Fri, 31 Jan 2003 08:41:26 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VDjFJ26718;
	Fri, 31 Jan 2003 08:45:15 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VDiuJ26683
	for <rohc@optimus.ietf.org>; Fri, 31 Jan 2003 08:44:56 -0500
Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06149
	for <rohc@ietf.org>; Fri, 31 Jan 2003 08:40:54 -0500 (EST)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0VDiQKV003462
	for <rohc@ietf.org>; Fri, 31 Jan 2003 14:44:26 +0100 (MET)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <DY5SM2DP>; Fri, 31 Jan 2003 14:44:26 +0100
Message-ID: <F005CD411D18D3119C8F00508B0874800A1446CF@ehubunt100.eth.ericsson.se>
From: "Lajos Zaccomer (ETH)" <Lajos.Zaccomer@eth.ericsson.se>
To: "'rohc@ietf.org'" <rohc@ietf.org>
Date: Fri, 31 Jan 2003 14:29:29 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-2"
Subject: [rohc] SigComp interop test with SIPstacks
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi,

We have a tool above the SigComp layer that is capable of sending and receiving messages, checking if the received message is expected and decompressed with the expected number of cycles, handling multiple compartments and the dispatcher.
If we are provided with complete message sequences, i.e. the SIP messages, what compartment they belong to and the order in that they should be sent and received, we are able to interoptest our SigComp implementation with other ones integrated in SIP.
I propose that the participants of SIPit, who come with a SIP integrated SigComp implementation should provide SIP message sequences to the interested parties. It helps preparing for the SIPit, so some time may be saved. It may also serve as a kind of pretest, which might reveal technical or implementation problems in time to correct.

Please, let me know if any of you are interested in this kind of testing.

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



From mailnull@www1.ietf.org  Fri Jan 31 10:02:03 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08779
	for <rohc-archive@odin.ietf.org>; Fri, 31 Jan 2003 10:02:03 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0VF5aY30928
	for rohc-archive@odin.ietf.org; Fri, 31 Jan 2003 10:05:36 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VF5aJ30925
	for <rohc-web-archive@optimus.ietf.org>; Fri, 31 Jan 2003 10:05:36 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08770
	for <rohc-web-archive@ietf.org>; Fri, 31 Jan 2003 10:01:32 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VF5LJ30892;
	Fri, 31 Jan 2003 10:05:21 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VF4EJ30850
	for <rohc@optimus.ietf.org>; Fri, 31 Jan 2003 10:04:14 -0500
Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08735
	for <rohc@ietf.org>; Fri, 31 Jan 2003 10:00:10 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <CN3DAJGK>; Fri, 31 Jan 2003 15:03:43 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED41804B88613@rsys002a.roke.co.uk>
From: "Surtees, Abigail" <abigail.surtees@roke.co.uk>
To: "'Lajos Zaccomer (ETH)'" <Lajos.Zaccomer@eth.ericsson.se>,
        "'rohc@ietf.org'" <rohc@ietf.org>
Date: Fri, 31 Jan 2003 15:03:33 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-2"
Subject: [rohc] RE: DAP issues
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi Zacco,

>If it is the decompressed message that should be sent back 
>uncompressed then it's all right. It needs a little 
>clarification in the doc. I e.g. thought it was the SigComp 
>message that should be sent back.

I think Zhigang clarified it in his mail on Tues, but we could add the following
line to section 2, paragraph 2.

"The entire DAP message (message-header + CRLF + message-body)
is returned. This allows the sender to compare what it sent with what the
receiver decompressed."

>I agree, let's keep it simple. That is why even the least 
>possibility of having dead lock should be removed! If we all 
>agree that a response should not be asked in case of a 
>response, let's have it specified in the doc! 

I've just reread this section of DAP 1b and there does seem to be an issue with
this that we must nail down.

Either
(as it states in DAP 1b) the receiver can set the need-response field to TRUE and 
both sender and receiver control the flow, allowing the possibility of infinite sending
(fixed by one end setting the field to FALSE)
or
(as I suggested in my last mail) the sender is in control of the message flow, the
receiver must NOT set the flag to TRUE. 

One thing to take into account is whether either approach will enable/prevent specific
test patterns.  The latter seems simpler to me, and I don't think it prevents anything.  
What does anyone else think?

>Including the 
>received header also unnecessarily complicates the DAP logic. 
>I think the header should not be included! Is there a special 
>reason to have it? If not let's keep it simple!

I'm not sure which header you are talking about here.  My understanding 
(again, correct me if I'm wrong) is that in the case where the sender asks
for a response we get:

sender							receiver
  ----------SigComp DAP_message_ 1(requesting response)-----> 

  <---------DAP_message_1 in clear text----------------------------------

  <---------SigComp DAP_message_2(no response)------------------

The body part of DAP_message_2 COULD be a copy of the body
part of DAP_message_1 if the receiver so chooses but it would have
to put its own DAP header on it so that the sender knows to which
compartment and endpoint it belongs and whether to accept or reject
it (the main reasons for DAP in the first place).

>It is VERY IMPORTANT regarding the very short available time 
>that there will be no interoperability problems with DAP. It 
>should be STRICT with NO MAY in the specification, only MUST!
>
Agreed.

Best regards,

Abbie

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



From mailnull@www1.ietf.org  Fri Jan 31 10:36:51 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09742
	for <rohc-archive@odin.ietf.org>; Fri, 31 Jan 2003 10:36:51 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h0VFeOO01199
	for rohc-archive@odin.ietf.org; Fri, 31 Jan 2003 10:40:24 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VFeOJ01196
	for <rohc-web-archive@optimus.ietf.org>; Fri, 31 Jan 2003 10:40:24 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09738
	for <rohc-web-archive@ietf.org>; Fri, 31 Jan 2003 10:36:19 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VFeAJ01179;
	Fri, 31 Jan 2003 10:40:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VFdcJ01120
	for <rohc@optimus.ietf.org>; Fri, 31 Jan 2003 10:39:38 -0500
Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09725
	for <rohc@ietf.org>; Fri, 31 Jan 2003 10:35:33 -0500 (EST)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0VFd6KV007628;
	Fri, 31 Jan 2003 16:39:06 +0100 (MET)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <DY5SNSBX>; Fri, 31 Jan 2003 16:39:06 +0100
Message-ID: <F005CD411D18D3119C8F00508B0874800A1446D2@ehubunt100.eth.ericsson.se>
From: "Lajos Zaccomer (ETH)" <Lajos.Zaccomer@eth.ericsson.se>
To: "'Surtees, Abigail'" <abigail.surtees@roke.co.uk>,
        "'rohc@ietf.org'"
	 <rohc@ietf.org>
Subject: RE: [rohc] RE: DAP issues
Date: Fri, 31 Jan 2003 16:37:21 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-2"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi Abbie,

see my inline comments below VVV

-----Original Message-----
From: Surtees, Abigail [mailto:abigail.surtees@roke.co.uk]
Sent: Friday, January 31, 2003 4:04 PM
To: 'Lajos Zaccomer (ETH)'; 'rohc@ietf.org'
Subject: [rohc] RE: DAP issues


Hi Zacco,

>If it is the decompressed message that should be sent back 
>uncompressed then it's all right. It needs a little 
>clarification in the doc. I e.g. thought it was the SigComp 
>message that should be sent back.

I think Zhigang clarified it in his mail on Tues, but we could add the following
line to section 2, paragraph 2.

"The entire DAP message (message-header + CRLF + message-body)
is returned. This allows the sender to compare what it sent with what the
receiver decompressed."

>> This is the message header I would not like to have in the returned message. The uncompressed message is just enough. Do we need the header information for some special purpose? If yes, I promise I will not resist.


>I agree, let's keep it simple. That is why even the least 
>possibility of having dead lock should be removed! If we all 
>agree that a response should not be asked in case of a 
>response, let's have it specified in the doc! 

I've just reread this section of DAP 1b and there does seem to be an issue with
this that we must nail down.

Either
(as it states in DAP 1b) the receiver can set the need-response field to TRUE and 
both sender and receiver control the flow, allowing the possibility of infinite sending
(fixed by one end setting the field to FALSE)
or
(as I suggested in my last mail) the sender is in control of the message flow, the
receiver must NOT set the flag to TRUE. 

One thing to take into account is whether either approach will enable/prevent specific
test patterns.  The latter seems simpler to me, and I don't think it prevents anything.  
What does anyone else think?

>> Agreed!

>Including the 
>received header also unnecessarily complicates the DAP logic. 
>I think the header should not be included! Is there a special 
>reason to have it? If not let's keep it simple!


>> see the header question above
I'm not sure which header you are talking about here.  My understanding 
(again, correct me if I'm wrong) is that in the case where the sender asks
for a response we get:

sender							receiver
  ----------SigComp DAP_message_ 1(requesting response)-----> 

  <---------DAP_message_1 in clear text----------------------------------

  <---------SigComp DAP_message_2(no response)------------------

The body part of DAP_message_2 COULD be a copy of the body
part of DAP_message_1 if the receiver so chooses but it would have
to put its own DAP header on it so that the sender knows to which
compartment and endpoint it belongs and whether to accept or reject
it (the main reasons for DAP in the first place).

>It is VERY IMPORTANT regarding the very short available time 
>that there will be no interoperability problems with DAP. It 
>should be STRICT with NO MAY in the specification, only MUST!
>
Agreed.

Best regards,

Abbie

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