Re: [Forces-protocol] Feedback: Section 6.4

Jamal Hadi Salim <hadi@znyx.com> Tue, 26 October 2004 11:02 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 HAA23171 for <forces-protocol-web-archive@ietf.org>; Tue, 26 Oct 2004 07:02:42 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMPJr-0000MT-3z for forces-protocol-web-archive@ietf.org; Tue, 26 Oct 2004 07:16:51 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMP61-0003Ff-L7; Tue, 26 Oct 2004 07:02:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMP4e-0002o7-6D for forces-protocol@megatron.ietf.org; Tue, 26 Oct 2004 07:01: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 HAA23088 for <forces-protocol@ietf.org>; Tue, 26 Oct 2004 07:01:05 -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 1CMPIH-0000Kl-Vs for forces-protocol@ietf.org; Tue, 26 Oct 2004 07:15:14 -0400
Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102604013955:42126 ; Tue, 26 Oct 2004 04:01:39 -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: <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> <055f01c4bb10$74623300$845c21d2@Necom.hzic.edu.cn>
Organization: ZNYX Networks
Message-Id: <1098788345.1045.48.camel@jzny.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2
Date: 26 Oct 2004 06:59:06 -0400
X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/26/2004 04:01:40 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/26/2004 04:03:36 AM, Serialize complete at 10/26/2004 04:03:36 AM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Content-Transfer-Encoding: 7bit
Cc: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>, ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, "Joel M. Halpern" <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: 4d87d2aa806f79fed918a62e834505ca
Content-Transfer-Encoding: 7bit

On Tue, 2004-10-26 at 00:01, Wang,Weiming wrote:


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

Aha! I think i see where the misunderstanding is;->
Weiming sees either a path like 6 or 1,2,3,4 as represented by _one_
_fixed_ sized element. In which case you have to find a way to pack both
representations into that fixed size element.

The suggested "path" representation is in fact _variable_.
>From the notes i sent earlier to you, the suggestion is:

----
 A possible path-data layout. 
----------------------------

OPER_TLV : = <PATH-DATA>
PATH-DATA := flags IDcount <IDs> [BLOCK_OR_KEY_NOTATION] [DATA]
The operational TLV contains an opcode in the T part. Its V
contains the PATH-DATA.
Opcodes discussed so far:
* SET (create, modify or both depending on PATH-DATA flags}
* DEL (remove an existing entity specified by PATH-DATA }
* GET (Access a entity specified in PATH-DATA }
* EV_S (subscribe to an event defined in PATH-DATA }
* EV_U (unsubscribe to an event defined in PATH-DATA }
-> IDs := a series of 32bit IDs (whose size is given by IDcount)
defining the path.
-> flags are used to further refine the operation to be applied
on the ID_TLV.
-> BLOCK_OR_KEY_NOTATION := optional different BLOCK or KEY extension
defined in section 4.2 and 4.3 of [1]
-> DATA : = Optional variable sized data dependent on PATH
and applied operations (eg GET will not have DATA).

-------

Well read the rest of the doc; and for completion the notes posted by
Steve/Zsolt.

cheers,
jamal



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