Re: [Forces-protocol] Feedback: Section 6.4

"Joel M. Halpern" <jhalpern@MEGISTO.com> Tue, 26 October 2004 11:19 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 HAA24565 for <forces-protocol-web-archive@ietf.org>; Tue, 26 Oct 2004 07:19:44 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMPaI-0000ek-8j for forces-protocol-web-archive@ietf.org; Tue, 26 Oct 2004 07:33:51 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMPLj-0006Md-Gl; Tue, 26 Oct 2004 07:18:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMPFO-0004uX-Vd for forces-protocol@megatron.ietf.org; Tue, 26 Oct 2004 07:12:15 -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 HAA24062 for <forces-protocol@ietf.org>; Tue, 26 Oct 2004 07:12:11 -0400 (EDT)
Received: from [64.254.114.117] (helo=megisto-e2k.megisto.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMPSr-0000WX-Sd for forces-protocol@ietf.org; Tue, 26 Oct 2004 07:26:21 -0400
Received: from JLaptop.megisto.com ([192.168.20.230]) by megisto-e2k.megisto.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 26 Oct 2004 07:11:06 -0400
Message-Id: <5.1.0.14.0.20041026070458.0239e560@mail.megisto.com>
X-Sender: jhalpern@mail.megisto.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 26 Oct 2004 07:05:03 -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: <055f01c4bb10$74623300$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> <5.1.0.14.0.20041025234709.022f37b8@mail.megisto.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 26 Oct 2004 11:11:06.0362 (UTC) FILETIME=[7D147DA0:01C4BB4C]
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

The path from the LFB instance to the element being targeted (by the SET or 
GET) is variable in length.  (I was going to write "must be variable in 
length".  One could craft a very complex mechanism to assign ids from a 
flat space to every such multi-step path.  But it does not seem a good idea.)

Yours,
Joel

At 12:01 PM 10/26/2004 +0800, Wang,Weiming wrote:
> > Remember that there may be structures inside structures, or arrays inside
> > structures inside arrays inside structures, ...
> >
> > Hence, a path is a sequence of identifiers,
>I suppose you are proposing the 'path' is variable in length, which  I 
>think may
>be not the original idea of a path as a 32 bit index for table only.
>If it is, i think the idea mathces more to what I proposed. Definitely, I 
>think
>the first ID appearing in the sequence is the attribute ID.
>
> >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.
>I have no doubt to agree with this. Just need to calrify that a path is more
>than 32 bits long, or there will be not enough bits.
>
>Thank you.
>Weiming


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