RE: [Forces-protocol] Feedback: Section 6.4

"Khosravi, Hormuzd M" <> Wed, 27 October 2004 07:25 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id DAA12500 for <>; Wed, 27 Oct 2004 03:25:06 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1CMiOz-0007Lr-S5 for; Wed, 27 Oct 2004 03:39:26 -0400
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1CMi9t-0005eD-FH; Wed, 27 Oct 2004 03:23:49 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1CMi7h-00054a-AG for; Wed, 27 Oct 2004 03:21:33 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id DAA12146 for <>; Wed, 27 Oct 2004 03:21:31 -0400 (EDT)
Received: from ([] by with esmtp (Exim 4.33) id 1CMiLV-0007Ga-KU for; Wed, 27 Oct 2004 03:35:50 -0400
Received: from ( []) by (8.12.9-20030918-01/8.12.9/d:,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9R7Kanx001483; Wed, 27 Oct 2004 07:20:36 GMT
Received: from ( []) by (8.12.9-20030918-01/8.12.9/d:,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9R7EBEm028099; Wed, 27 Oct 2004 07:14:11 GMT
Received: from ([]) by (SAVSMTP with SMTP id M2004102700204914628 ; Wed, 27 Oct 2004 00:20:49 -0700
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.0); Wed, 27 Oct 2004 00:20:49 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Forces-protocol] Feedback: Section 6.4
Date: Wed, 27 Oct 2004 00:20:03 -0700
Message-ID: <468F3FDA28AA87429AD807992E22D07E0257923E@orsmsx408>
Thread-Topic: [Forces-protocol] Feedback: Section 6.4
Thread-Index: AcS7SyD1af3uDwsWTVK5oYcJhVT4DQAqT6Wg
From: "Khosravi, Hormuzd M" <>
To: <>, "Wang,Weiming" <>
X-OriginalArrivalTime: 27 Oct 2004 07:20:49.0645 (UTC) FILETIME=[7C1689D0:01C4BBF5]
X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Content-Transfer-Encoding: quoted-printable
Cc:,,, "Joel M. Halpern" <>, Ligang Dong <>, Robert Haas <>
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: forces-protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Content-Transfer-Encoding: quoted-printable

Jamal, Weiming,

I finally got the chance to read some of these emails...sorry for not
responding earlier. In general, we will need the concept of PATH atleast
for Query messages (GET), but I don't believe from any of the emails
that I have read so far that there was any concensus on what this would
look like. Jamal has a reasonable proposal which needs more discussion
and refinement.

Some specific comments on Jamal's proposal so far...

Where is the Table ID ? Is this part of the path IDs?
I don't believe we need any Flags in the path, this is similar to the
comment that Joel had as well.
Also, for Config msgs, I think the path can be part of the data itself,
but lets discuss this further...cause I am not sure if you guys agree
with this,

Talk to you soon,


-----Original Message-----
From: Jamal Hadi Salim [] 
Sent: Tuesday, October 26, 2004 3:59 AM
To: Wang,Weiming
Cc: Joel M. Halpern; Khosravi, Hormuzd M;;;; Ligang Dong; Robert Haas
Subject: Re: [Forces-protocol] Feedback: Section 6.4

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. 

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


Forces-protocol mailing list