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

"Wang,Weiming" <wmwang@mail.hzic.edu.cn> Mon, 25 October 2004 03:49 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 XAA26886 for <forces-protocol-web-archive@ietf.org>; Sun, 24 Oct 2004 23:49:45 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLw53-0003nc-1n for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 00:03:37 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLvni-0004PV-Vs; Sun, 24 Oct 2004 23:45:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLvmf-0004HO-EU for forces-protocol@megatron.ietf.org; Sun, 24 Oct 2004 23:44:37 -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 XAA26600 for <forces-protocol@ietf.org>; Sun, 24 Oct 2004 23:44:34 -0400 (EDT)
Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CLvzs-0003Y5-L8 for forces-protocol@ietf.org; Sun, 24 Oct 2004 23:58:26 -0400
Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Mon, 25 Oct 2004 12:03:35 +0800 (CST)
Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id <B0000088164@mail.gsu.cn>; Mon, 25 Oct 2004 11:39:18 +0800
Message-ID: <006f01c4ba44$7f3c7eb0$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> <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>
Subject: Re: [Forces-protocol] Re: querry message (path vs attribute)
Date: Mon, 25 Oct 2004 11:41:22 +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: 1676547e4f33b5e63227e9c02bd359e3
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: 093efd19b5f651b2707595638f6c4003

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

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.


>
> > > 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'?

>I dont think that it matters if theres a table involved
> or not. Neither if its a single attribute that has nothing to do with a
> table.
> Is the above still under discussion? Thats not the impression i have.
>
> cheers,
> jamal
>
>
>



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