Re: [Forces-protocol] Feedback: Section 6.4

"Joel M. Halpern" <jhalpern@MEGISTO.com> Tue, 26 October 2004 03:52 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 XAA07892 for <forces-protocol-web-archive@ietf.org>; Mon, 25 Oct 2004 23:52:03 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMIb2-0000mk-Eh for forces-protocol-web-archive@ietf.org; Tue, 26 Oct 2004 00:06:08 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMIMC-0003Ig-CV; Mon, 25 Oct 2004 23:50:48 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMILF-00032r-MO for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 23:49:50 -0400
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 XAA07399 for <forces-protocol@ietf.org>; Mon, 25 Oct 2004 23:49:46 -0400 (EDT)
Received: from [64.254.114.117] (helo=megisto-e2k.megisto.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMIYc-0000gy-UY for forces-protocol@ietf.org; Tue, 26 Oct 2004 00:03:50 -0400
Received: from JLaptop.megisto.com ([192.168.20.235]) by megisto-e2k.megisto.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 25 Oct 2004 23:48:39 -0400
Message-Id: <5.1.0.14.0.20041025234709.022f37b8@mail.megisto.com>
X-Sender: jhalpern@mail.megisto.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 25 Oct 2004 23:48:36 -0400
To: "Wang,Weiming" <wmwang@mail.hzic.edu.cn>, <hadi@znyx.com>
From: "Joel M. Halpern" <jhalpern@MEGISTO.com>
Subject: Re: [Forces-protocol] Feedback: Section 6.4
In-Reply-To: <053c01c4bb0a$47497500$845c21d2@Necom.hzic.edu.cn>
References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <C4CB0B3C-251F-11D9-9DB1-000393CC2112@psg.com> <1098562959.1096.80.camel@jzny.localdomain> <1098564534.1098.106.camel@jzny.localdomain> <130801c4b9c3$ac205d60$845c21d2@Necom.hzic.edu.cn> <1098623794.1255.145.camel@jzny.localdomain> <007001c4ba44$fc908a50$845c21d2@Necom.hzic.edu.cn> <1098678563.1097.319.camel@jzny.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 26 Oct 2004 03:48:39.0882 (UTC) FILETIME=[AE251AA0:01C4BB0E]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>, ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, Ligang Dong <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.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5

Remember that there may be structures inside structures, or arrays inside 
structures inside arrays inside structures, ...

Hence, a path is a sequence of identifiers, each of which is either a 
subscript or an element identifier within the containing scope (initially 
the LFB classs definition, then progressive the structures selected by the 
earlier path elements.
For simplicity, I suggest we make all the identifiers 32 bits.

Yours,
Joel

At 11:17 AM 10/26/2004 +0800, Wang,Weiming wrote:
> > To point to first entry of datatable: 6,1
>[Weiming]I'm glad to see this. It also means you'v agreed that the 'path'
>includes one subsection  which is for attribute ID, right? Now the problem is,
>how many bits are you going to use for such ID, 8 bits or 16bits? I 
>suppose you
>will not use a variable size for this ID. Whether the ID length is variable or
>not, we  then can both reasonably think the 'path' as composed of follows:
>                 Path : = AttributeID  Index
>  that really matches my idea. I also think  it mathces your idea too as
>presented in your example here as 6.1, 6.2.3, etc.
>
>To summarize, what I proposed actually include two thoughts:
>a) Attribute ID is necessary;
>b) the attribute ID should appear in the protocol layer. The followed 
>Index can
>be included in Data field, becaue not all attributes need Index (they may only
>have one entry).


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