Re: [Forces-protocol] Feedback: Section 6.4

Jamal Hadi Salim <hadi@znyx.com> Mon, 25 October 2004 04:30 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 AAA29575 for <forces-protocol-web-archive@ietf.org>; Mon, 25 Oct 2004 00:30:36 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLwia-0004Vq-On for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 00:44:29 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLwV1-0000uT-8P; Mon, 25 Oct 2004 00:30:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLwUB-0000pg-38 for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 00:29:35 -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 AAA29429 for <forces-protocol@ietf.org>; Mon, 25 Oct 2004 00:29:32 -0400 (EDT)
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 1CLwhY-0004U6-3E for forces-protocol@ietf.org; Mon, 25 Oct 2004 00:43:24 -0400
Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102421315628:40112 ; Sun, 24 Oct 2004 21:31:56 -0700
Subject: Re: [Forces-protocol] Feedback: Section 6.4
From: Jamal Hadi Salim <hadi@znyx.com>
To: "Wang,Weiming" <wmwang@mail.hzic.edu.cn>
In-Reply-To: <007001c4ba44$fc908a50$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>
Organization: ZNYX Networks
Message-Id: <1098678563.1097.319.camel@jzny.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2
Date: 25 Oct 2004 00:29:24 -0400
X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/24/2004 09:31:58 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/24/2004 09:32:04 PM, Serialize complete at 10/24/2004 09:32:04 PM
Content-Type: multipart/mixed; boundary="=-1kNF6BOeofa0nzts3XrU"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 054490fec19f6a94c68e63428d06db69
Cc: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>, ram.gopal@nokia.com, jhalpern@megisto.com, avri@psg.com, forces-protocol@ietf.org, 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
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: 8df1ceff7d5e1ba4a25ab9834397277b

On Sun, 2004-10-24 at 23:44, Wang,Weiming wrote:
> ----- Original Message -----
> From: "Jamal Hadi Salim" <hadi@znyx.com>
> 

> > So while you are defining that at the top; i think its also important to
> > have a subsection somewhere which says something along the lines of:
> >
> > ---
> > Every attribute within an LFB will have a unique 32 bit ID defined
> > during the LFB definition. This allows mapping any attribute within an
> > LFB to a path not unlike the SNMP OID.
> >
> > Below is an illustration of a complex example and how the different
> > attributes could be accessed.
> >
> > Assume LFB Class A.
> > It contains two Arrays, B, and C (assigned identifiers 1 and 2)
> > A also contains a structure of type Stoo with a human name F.
> > F is assigned ID 3.
> > A also contains two attributes, D and E assigned identifiers 4 and 5.
>
> [Weiming]I suppose the attribute identifier (4, 5) will be assigned by XML as
> you mentioned (I see some necessity to be defined by IANA). Definitely, user
> will not be able to define the ID, or there will be no operabitlity.
> 

Right. As an example in noop.xml i posted earlier, foo1 has ID of 3
and foo2 has ID of 4. Thats defined when noop.xml was defined.

> > Array B is an array, indexed as a table, whose contents are int32s.
> > Array C is an array, indexed as a table, whose contents are a structure
> > named Star.
> > Stoo type structures contain elements X and Y, each characters,
> > assigned identifiers 1 and 2.
> > Star contains An element N (a sting), assigned identifier 1, and an
> > array
> > Arr, assigned identifier 2, indexed as a table, containing int32s.
> >
> > To reference entities within an LFB instance of Class A, selectors
> > are as follows:
> >
> > 1, meaning the full array B
> > 3, meaning the full structure named F.
> > 2, 7 meaning the full structure in the seventh entry of the array C.
> > 4 means the attribute D
> > 2, 8, 2, 9 meaning the 9th number in the array in the structure in the
> > eigth slot of the array C.
> > Interpreting the string 2, 8, 2, 9 clearly requires knowing the correct
> > type definition.
> > -------
>
> [Weiming]Followed by above comments, a very simple question is how will you
> address the D and E attributes as you mentioned as two different attributes? I
> see it's possible only if you save a section inside the 32bit 'path'
> specifically for attribute type ID. That means this section are not allowed
> freely used by users. Because of this, i then prefer to have a specific field
> (AttributeTypeID, which I refered as attribute ID) for it. Note that I'm not
> saying 'path' is useless, I just think it can be followed in Data field.
> 

Lets take an example of noop, since the xml for that is there and its a
very simple example.

The class NOOP is 5. owned by IANA.
It has a simple table called datatable whose ID is 6. Defined at xml
creation.
To point to first entry of datatable: 6,1
to point to foo1 within entry 2 of datatable: 6,2,3
to point to foo2 of entry 3 of datatable: 6,3,4

I hope this clears it. I have attached two docs i worked on to 
clarify this.

As i said earlier, the path issue is resolved but not the data packing.
Of course if you disagree we could continue that discussion.
As you will notice in these docs, the text clearly states that the 
data packing is not resolved.

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