Re: [rohc] Generic scheme of list compression

Lars Eggert <lars.eggert@nokia.com> Sat, 08 August 2009 07:49 UTC

Return-Path: <lars.eggert@nokia.com>
X-Original-To: rohc@core3.amsl.com
Delivered-To: rohc@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26A103A6B29 for <rohc@core3.amsl.com>; Sat, 8 Aug 2009 00:49:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.394
X-Spam-Level:
X-Spam-Status: No, score=-1.394 tagged_above=-999 required=5 tests=[AWL=-0.791, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1XqW24JYH5Z for <rohc@core3.amsl.com>; Sat, 8 Aug 2009 00:49:38 -0700 (PDT)
Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id AB1C83A6CA4 for <rohc@ietf.org>; Sat, 8 Aug 2009 00:49:19 -0700 (PDT)
Received: from [10.0.1.5] (cs95024.pp.htv.fi [212.90.95.24]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n787nDJY053522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 8 Aug 2009 10:49:13 +0300 (EEST) (envelope-from lars.eggert@nokia.com)
Message-Id: <D85B2766-C847-443E-9C4B-BA1E6E5F16E7@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
To: cai.wei2@zte.com.cn
In-Reply-To: <OF3CA62DF0.2F42EA39-ON4825760C.000E8B27-4825760C.001278A3@zte.com.cn>
Content-Type: multipart/signed; boundary="Apple-Mail-32-827613977"; micalg="sha1"; protocol="application/pkcs7-signature"
Mime-Version: 1.0 (Apple Message framework v936)
Date: Sat, 08 Aug 2009 10:49:13 +0300
References: <OF3CA62DF0.2F42EA39-ON4825760C.000E8B27-4825760C.001278A3@zte.com.cn>
X-Mailer: Apple Mail (2.936)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [195.148.124.194]); Sat, 08 Aug 2009 10:49:14 +0300 (EEST)
Cc: "rohc@ietf.org" <rohc@ietf.org>
Subject: Re: [rohc] Generic scheme of list compression
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Robust Header Compression <rohc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rohc>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Aug 2009 07:49:39 -0000

Hi,

please refrain from including legal disclaimers in emails to the IETF  
- they have no effect. See a message from the IETF Chair at http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg02914.html 
, which I'm including for your convenience below.

Thanks,
Lars

> Sometimes people send IETF email with attached legal disclaimers,
> usually inserted automatically by their employer's mail system.
> These disclaimers make assertions about confidentiality and may  
> contain
> phrases like "If you are not the intended recipient be aware that any
> disclosure, copying, distribution or use of the contents of this
> information is prohibited."
>
> You are reminded that IETF contributions are automatically subject
> to RFC 3978, which explicitly states in Section 3.2 that:
>
>   Each Contributor agrees that any statement in a Contribution,  
> whether
>   generated automatically or otherwise, that states or implies that  
> the
>   Contribution is confidential or subject to any privilege, can be
>   disregarded for all purposes, and will be of no force or effect.
>
> Therefore, any such disclaimers attached to IETF email can be ignored
> for IETF purposes.
>
> However, we strongly advise all participants to take all possible
> steps to prevent the addition of such disclaimers. Among other issues,
> some other standards organizations will refuse to consider any liaison
> message from an IETF source that contains such a disclaimer.
>


On 2009-8-8, at 6:21, cai.wei2@zte.com.cn wrote:

>
> "In contrast to subsequent schemes, this scheme does not rely on a
>  reference list having been established.  The entire list is sent,
>  using table based compression for each individual item. The generic
>  scheme is always used when establishing the context of the  
> decompressor
>  and may also be used at other times, as the compressor sees fit."
>
> When ref_list has been established and the curr_list is the same as  
> ref_list,
>
> Could we adopt generic scheme? If Not, How can we Encode?
>
> Thanks!
> <ATT00001.jpg>
>
> caiwei 167981
> LTE Development Department | LTE开发部
> <ATT00002.jpg>
> Product Marketing System
> 产品市场体系
> D3-06, ZTE Corp., No.10 South Tangyan Rd.,
> Hi-tech Industrial Development Zone, Xi'an,
> P.R.China, 710065
> Tel:+86-29-88724112, 15801916689
> Email:167981@zte.com.cn
>
>
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this  
> mail is solely property of the sender's organization. This mail  
> communication is confidential. Recipients named above are obligated  
> to maintain secrecy and are not permitted to disclose the contents  
> of this communication to others.
> This email and any files transmitted with it are confidential and  
> intended solely for the use of the individual or entity to whom they  
> are addressed. If you have received this email in error please  
> notify the originator of the message. Any views expressed in this  
> message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam  
> system.
> <ATT00003.txt>