Re: [Forces-protocol] Re: querry message (path vs attribute)

Jamal Hadi Salim <hadi@znyx.com> Mon, 25 October 2004 04:24 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 AAA28966 for <forces-protocol-web-archive@ietf.org>; Mon, 25 Oct 2004 00:24:39 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLwcp-0004Mm-W9 for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 00:38:32 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLwOh-0000Wq-0D; Mon, 25 Oct 2004 00:23:55 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLwK3-0000IH-Jw for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 00:19:08 -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 AAA28659 for <forces-protocol@ietf.org>; Mon, 25 Oct 2004 00:19:04 -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 1CLwXQ-0004Gs-R6 for forces-protocol@ietf.org; Mon, 25 Oct 2004 00:32:57 -0400
Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102421212517:40107 ; Sun, 24 Oct 2004 21:21:25 -0700
Subject: Re: [Forces-protocol] Re: querry message (path vs attribute)
From: Jamal Hadi Salim <hadi@znyx.com>
To: "Wang,Weiming" <wmwang@mail.hzic.edu.cn>
In-Reply-To: <006f01c4ba44$7f3c7eb0$845c21d2@Necom.hzic.edu.cn>
References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <005b01c4b907$242b1790$020aa8c0@wwm1> <417AA8B6.1040601@zurich.ibm.com> <1098558745.1097.42.camel@jzny.localdomain> <122b01c4b9be$50fa1cf0$845c21d2@Necom.hzic.edu.cn> <1098623230.1255.136.camel@jzny.localdomain> <006f01c4ba44$7f3c7eb0$845c21d2@Necom.hzic.edu.cn>
Organization: ZNYX Networks
Message-Id: <1098677932.1255.309.camel@jzny.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2
Date: 25 Oct 2004 00:18:52 -0400
X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/24/2004 09:21:26 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/24/2004 09:21:37 PM, Serialize complete at 10/24/2004 09:21:37 PM
Content-Type: multipart/mixed; boundary="=-VbkBesYBf1yqWiKpDjbM"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07
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
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: 17e5edc4dfd335965c1d21372171c01c

On Sun, 2004-10-24 at 23:41, Wang,Weiming wrote:
> Jamal,
> 
> Hormuzd, pls also give some feadback. I also add Joel to the list again for the
> discussion.
> 
> Regards,
> Weiming
> ----- Original Message -----
> From: "Jamal Hadi Salim" <hadi@znyx.com>
> Subject: Re: [Forces-protocol] Re: querry message (path vs attribute)
> 
> 
> > Weiming,
> >
> > On Sun, 2004-10-24 at 07:40, Wang,Weiming wrote:
> > > Jamal,
> > >
> > > Firstly, I think it may be unwise to remove some editorial note when the
> isuuse
> > > is still under discussion. I can clearly see many different opinions
> regarding
> > > the issue. Then, some of my thougt on adding such an editorial note as
> below.
> > >
> >
> > Is the concept of path still under discussion Weiming? Thats not my
> > impression. And if not, why does it matter if the path is constructed
> > from a single attribute or via table of table7 index 3 which is table8 ?
> [Weiming]Jamal, it's really a under discussion topic. I can see different view
> other than from me, you may miss me one person :), but it's true we have more. I
> stopped the discussion for I paid more attention to draft rewriting. At least I
> think Hormuzd also has some different views.
> >
> > > Regards,
> > > Weiming
> > > ----- Original Message -----
> > > From: "Jamal Hadi Salim" <hadi@znyx.com>
> > >
> > > >
> > > > I think we need to add a definition for attribute.
> > > > As far as iam concerned there is no such thing as a "attribute ID".
> > > [Weiming] Then, I just can not see how we can recognize different attributes
> in
> > > a LFB. Note that a 'Path' is a ID that is used and defined by USERS rather
> than
> > > standadized by IETF, therefore it's impossible to recoganize different
> > > attributes by 'path', and more, if the attribute ID is defined by USERS,
> there
> > > will be no interoperability. What I see the 'Attribute ID' is a standardized
> by
> > > IANA Identifier that is assigned to different attributes in all LFBs.
> >
> > The attribute IDs are defined by the person(s) who create the XML.
> > The document/ClassID - that i can see as being owned by IANA.
> 
> [Weiming] Even if the attribute(type) ID will only be defined by XML which
> define LFBs (I still see the necessity for IANA to standardize the ID), it has
> already meant the ID will not be assigned by USERS.

Not defined by users, rather static - defined at LFB XML template
creation time. OTOH, there are some more dynamic IDs that are usable
such as a table index.

>  Then, if you want to have
> 'path' include the ID, I suppose we should leave a specific section for the ID,
> and the use of the section will be limited only for attribute type ID. To do
> like this, I more prefer to have it as a separate spicific field. Note that I'm
> not saying in any case, the 'path' is useless, I just suppose it can be put in
> Data field. Actually hat I think the more reasonable addressing map for LFB
> should be as follows:
> 
>                                 LFB class
>                                /      \
>                         LFB Instance  ...
>                         /    \
>              Attribue Type   ...
>                 /         \
>     Path to entries inside  ...
> 
> Rather than:
>                                         LFB class
>                                        /      \
>                                 LFB Instance  ...
>                                 /        \
>                Path to  entries   ...
>                 /         \
>         Attribute Type    ...
> 

Why do you have the attribute type? To get to the attribute i.e to know
its path, you dont need to know its type.

> The path can really be defined in Data as:
> 
> Data : = Path <Entry>
> 
> Can you tell me what's the harm if we just define the 'path' one step down to
> the Data field. I just see it more flexible.
> 

Above is what we have been refering to as path-data. Entry is the data.


> 
> >
> > > > What you specify is a path similar to an OID. Whether that path
> > > > happens to be on an attribute, a table, an entry is not important
> > > I see it may be important, the reason is as above.
> > > > because that wuill be the lement you are pointing to.
> > > > so lets remove this from the query section
> > > [Weiming]I'v already put the 'path' as main select and the 'attribute
> ID/table
> > > ID' as a select for discussion. I don't have any intention to deny the
> 'path'.
> > > Therefore, I don't think it's reasonable currently to remove the note.
> > >
> >
> > I think we need to define how a path is selected once; then use the word
> > path everywhere.
> [Weiming]So can you give more definition for the 'Path' then? Does it include
> 'AttributeTypeID'?
> 

'AttributeTypeID' is not needed to get to the element. But the ID is
needed. I have attached the noop LFB we looked at a while back, it may
help reminding you a little ;->

cheers,
jamal


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