Re: [Forces-protocol] Feedback: Section 6.4

"Wang,Weiming" <wmwang@mail.hzic.edu.cn> Mon, 25 October 2004 03:51 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 XAA27059 for <forces-protocol-web-archive@ietf.org>; Sun, 24 Oct 2004 23:51:36 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLw6p-0003py-Uq for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 00:05:28 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLvsh-0004kY-H7; Sun, 24 Oct 2004 23:50:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLvpY-0004Ta-DV for forces-protocol@megatron.ietf.org; Sun, 24 Oct 2004 23:47:36 -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 XAA26726 for <forces-protocol@ietf.org>; Sun, 24 Oct 2004 23:47:33 -0400 (EDT)
Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CLw2n-0003c1-Mc for forces-protocol@ietf.org; Mon, 25 Oct 2004 00:01:25 -0400
Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Mon, 25 Oct 2004 12:07:05 +0800 (CST)
Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id <B0000088171@mail.gsu.cn>; Mon, 25 Oct 2004 11:42:48 +0800
Message-ID: <007001c4ba44$fc908a50$845c21d2@Necom.hzic.edu.cn>
From: "Wang,Weiming" <wmwang@mail.hzic.edu.cn>
To: <hadi@znyx.com>
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>
Subject: Re: [Forces-protocol] Feedback: Section 6.4
Date: Mon, 25 Oct 2004 11:44:52 +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: 6d95a152022472c7d6cdf886a0424dc6
Cc: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>, ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, jhalpern@megisto.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.3 (/)
X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8

----- Original Message -----
From: "Jamal Hadi Salim" <hadi@znyx.com>

> On Sun, 2004-10-24 at 08:19, Wang,Weiming wrote:
>
> > > Isnt everything an LFB? Why not say that its for querying LFBs?
> > [Weimig]it's just a top level description I think we need. i don't think it
> > conflict with the ideas of LFBs. Maybe we can add one more sentense as "The
> > information of a ForCES element all reside in LFBs in the element,
therefore,
> > query message will actually query the LFBs for kinds of information." Does
it
> > work?
>
> 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.

> 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.

cheers,
weiming

>
>
> > >
> > > - 6.4.1  Query Message
> > >
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > |    Type = GET                 |               Length          |
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > |                        Path(or Attribute ID?)                 |
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > |                            Query Data                         |
> > >                                                               .
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >
> > >
> > > Should really be:
> > >
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > |    Type = GET                 |               Length          |
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > |                        Path to queried data                   |
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > [Weiming] This may be better described in the followed description. So,
Avri,
> > could you please add the 'Path to queried data' after the Path description,
just
> > before the [[Under discussion and TBD]
> >
> > Again, I think it may be better to leave the discussion topic on attribute
> > ID/table ID here.
>
>
> Read my text above on examples. If you still think that this is still
> under discussion, lets tag it as so for now just so we can release the
> draft. My opinion is that we have agreement on the path concept.
>
> cheers,
> jamal
>
>



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