Re: [Forces-protocol] Data Encoding

"Wang,Weiming" <wmwang@mail.hzic.edu.cn> Thu, 18 November 2004 12:22 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 HAA18713 for <forces-protocol-web-archive@ietf.org>; Thu, 18 Nov 2004 07:22:24 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUlLX-0008AF-T0 for forces-protocol-web-archive@ietf.org; Thu, 18 Nov 2004 07:25:08 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUlER-0007X1-RN; Thu, 18 Nov 2004 07:17:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUlBx-00077h-Ij for forces-protocol@megatron.ietf.org; Thu, 18 Nov 2004 07:15:18 -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 HAA18318 for <forces-protocol@ietf.org>; Thu, 18 Nov 2004 07:15:10 -0500 (EST)
Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CUlE1-00081d-S1 for forces-protocol@ietf.org; Thu, 18 Nov 2004 07:17:56 -0500
Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 58110.341813895; Thu, 18 Nov 2004 20:38:46 +0800 (CST)
Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id <B0000117575@mail.gsu.cn>; Thu, 18 Nov 2004 20:12:18 +0800
Message-ID: <198e01c4cd67$a6b0d9b0$845c21d2@Necom.hzic.edu.cn>
From: "Wang,Weiming" <wmwang@mail.hzic.edu.cn>
To: <hadi@znyx.com>, "Joel M. Halpern" <joel@stevecrocker.com>
References: ocaldomain><009e01c4cb24$ba144bd0$020aa8c0@wwm1> <1100610279.1152.33.camel@jzny.localdomain> <002501c4ccb4$809d2b60$020aa8c0@wwm1> <1100702562.1140.75.camel@jzny.localdomain>
Subject: Re: [Forces-protocol] Data Encoding
Date: Thu, 18 Nov 2004 20:10:53 +0800
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>, "\(Ram Gopal \)" <ram.gopal@nokia.com>, Avri Doria <avri@acm.org>, forces-protocol@ietf.org, Patrick Droz <dro@zurich.ibm.com>, zsolt@modularnet.com, Steve Blake <slblake@petri-meat.com>, David.Putzolu@intel.com, Dong Ligang <donglg@mail.hzic.edu.cn>, Robert Haas <rha@zurich.ibm.com>
X-BeenThere: forces-protocol@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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.3 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955

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
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
2. Key is replaced by Subpath, which allows more general multiple level IDs.
3. block operation is included in the PathTLV, where indices appear.
4. Data part should be a TLV, or else there will be a parse problem.

Cheers,
Weiming

----- Original Message -----
From: "Jamal Hadi Salim" <hadi@znyx.com>
>
> Essentially grammar becomes:
>
> OPER_TLV : = <PATH-DATA>
> PATH-DATA := <PATH_TLV> [PATH_EXTENSIONS] [DATA]
> PATH_TLV := flags IDcount <IDs>
> PATH_EXTENSIONS := BLOCK_NOTATION | KEY_INFO
> KEY_INFO := PATH-DATA
> BLOCK_NOTATION :=   BLOCK_RANGE_INDEX_TLV |
>                     BLOCK_COUNT_INDEX_TLV |
>                     BLOCK_LIST_INDEX TLV
[Weiming]The BlockTLV will acompany indices where it appear.
>
> We dont distinguish between indices and IDs
>
> I havent thought clearly about this but the recursive nature may
> introduce loops.
>
> Thoughts?
>
> cheers,
> jamal
>
>
>



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