Re: [Forces-protocol] Data Encoding

Jamal Hadi Salim <hadi@znyx.com> Thu, 18 November 2004 22:15 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24445 for <forces-protocol-web-archive@ietf.org>; Thu, 18 Nov 2004 17:15:46 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUubq-0000aJ-TX for forces-protocol-web-archive@ietf.org; Thu, 18 Nov 2004 17:18:37 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUuQE-0006ei-Dw; Thu, 18 Nov 2004 17:06:34 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUuB8-0001fT-Ha for forces-protocol@megatron.ietf.org; Thu, 18 Nov 2004 16:50:59 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20962 for <forces-protocol@ietf.org>; Thu, 18 Nov 2004 16:50:55 -0500 (EST)
Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUuDp-00088a-11 for forces-protocol@ietf.org; Thu, 18 Nov 2004 16:53:46 -0500
Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004111813542366:28182 ; Thu, 18 Nov 2004 13:54:23 -0800
Subject: Re: [Forces-protocol] Data Encoding
From: Jamal Hadi Salim <hadi@znyx.com>
To: "Wang,Weiming" <wmwang@mail.hzic.edu.cn>
In-Reply-To: <198e01c4cd67$a6b0d9b0$845c21d2@Necom.hzic.edu.cn>
References: ocaldomain><009e01c4cb24$ba144bd0$020aa8c0@wwm1> <1100610279.1152.33.camel@jzny.localdomain> <002501c4ccb4$809d2b60$020aa8c0@wwm1> <1100702562.1140.75.camel@jzny.localdomain> <198e01c4cd67$a6b0d9b0$845c21d2@Necom.hzic.edu.cn>
Organization: Znyx Networks
Message-Id: <1100814638.1085.42.camel@jzny.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2
Date: Thu, 18 Nov 2004 16:50:38 -0500
X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/18/2004 01:54:23 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/18/2004 01:54:40 PM, Serialize complete at 11/18/2004 01:54:40 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Content-Transfer-Encoding: 7bit
Cc: "(Ram Gopal )" <ram.gopal@nokia.com>, Steve Blake <slblake@petri-meat.com>, "Joel M. Halpern" <joel@stevecrocker.com>, Dong Ligang <donglg@mail.hzic.edu.cn>, "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>, Avri Doria <avri@acm.org>, forces-protocol@ietf.org, Patrick Droz <dro@zurich.ibm.com>, zsolt@modularnet.com, David.Putzolu@intel.com, Robert Haas <rha@zurich.ibm.com>
X-BeenThere: forces-protocol@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: hadi@znyx.com
List-Id: forces-protocol <forces-protocol.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/forces-protocol>, <mailto:forces-protocol-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/forces-protocol>
List-Post: <mailto:forces-protocol@ietf.org>
List-Help: <mailto:forces-protocol-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/forces-protocol>, <mailto:forces-protocol-request@ietf.org?subject=subscribe>
Sender: forces-protocol-bounces@ietf.org
Errors-To: forces-protocol-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Content-Transfer-Encoding: 7bit

Weiming,

On Thu, 2004-11-18 at 07:10, Wang,Weiming wrote:
> Jamal and Joel,
> 
> In reply to Joel, I should say the compromise may not be necessary, for it seems
> we all tend to think indices and IDs will be interleaved under the condition
> that we should use indices. Pls allow me to try to propose a path scheme(I hope
> not too messy) as below:
> 
>         PathTLV:= Index|FieldID <Index|RangeMark|FieldID>+
> 
> Then,
> 1) path = FieldID1 Index1 Field2 --- for single index case

I dont follow: Why do you need all that to say get a simple top level
attribute?

> 2) path = FieldID1 Index1 Index2 Index3 Field2 --- for listed indices case
> 3) path = FieldID1 Index1 RangeMark Index2 Field2 --- for block index1 to index2
> case
> 4) path = FieldId1 Index1 Index2 RangeMark Index3 Field2 --- for list and
> combined block indices cases
> 
> Where the length is controlled by the TLV length.
> 
> Based on this path TLV, and with Jamal's scheme in mind, I see the OpTLV format
> as below:
> 
>         OpTLV:= MainPathTLV [SubPathTLV VALUE]+ [DataTLV]
> 
> MainPathTLV and SubPathTLV all have uniform formats as a PathTLV.
> 
> Points a little different from Jamal's are:
> 1. IDcount removed, instead using PathTLV's length to control

I have to think about it - it should probably be able to remove it. What
happened to the flags?

> 2. Key is replaced by Subpath, which allows more general multiple level IDs.

I am not sure i followed this.
Can you reproduce the use cases i showed?

> 3. block operation is included in the PathTLV, where indices appear.

Same comment as above

> 4. Data part should be a TLV, or else there will be a parse problem.
> 

It is a TLV as proposed earlier.

Start with the use cases i used and show how you achieve the connection
if possible.

you can ignore the key based example or include it if it will help to
see the value easier.

cheers,
jamal



_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol