Re: [Fwd: [Forces-protocol] Presentation of the options forLFB-level multicast]

Jamal Hadi Salim <> Sat, 13 November 2004 21:59 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id QAA03163 for <>; Sat, 13 Nov 2004 16:59:44 -0500 (EST)
Received: from ([]) by with esmtp (Exim 4.33) id 1CT5xZ-0004ka-1C for; Sat, 13 Nov 2004 17:01:29 -0500
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1CT5ks-0004Ji-HH; Sat, 13 Nov 2004 16:48:22 -0500
Received: from ([] by with esmtp (Exim 4.32) id 1CT5Wc-000281-4D for; Sat, 13 Nov 2004 16:33:39 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id QAA01683 for <>; Sat, 13 Nov 2004 16:33:36 -0500 (EST)
Received: from ([] by with esmtp (Exim 4.33) id 1CT5YG-0003Vz-LT for; Sat, 13 Nov 2004 16:35:21 -0500
Received: from localhost ([]) by (Lotus Domino Release 5.0.11) with ESMTP id 2004111313370504:21697 ; Sat, 13 Nov 2004 13:37:05 -0800
Subject: Re: [Fwd: [Forces-protocol] Presentation of the options forLFB-level multicast]
From: Jamal Hadi Salim <>
To: "Joel M. Halpern" <>
In-Reply-To: <>
References: <> <005101c4c408$dc341600$020aa8c0@wwm1> <1099752095.1037.11.camel@jzny.localdomain> <003201c4c46d$1bbce4a0$020aa8c0@wwm1> <004201c4c4ec$61d34c20$020aa8c0@wwm1> <1099829057.2165.18.camel@jzny.localdomain> <00bd01c4c536$fb418ee0$020aa8c0@wwm1> <1099885892.2167.13.camel@jzny.localdomain> <132001c4c551$86023150$> <1099911200.2169.29.camel@jzny.localdomain> <134f01c4c585$216584c0$> <> <142a01c4c6d6$13569980$> <1100100893.2210.24.camel@jzny.localdomain> <14fc01c4c79f$75231f20$> <> <155001c4c8c0$5eb73ec0$> <1100269665.1106.30.camel@jzny.localdomain> <156501c4c8c5$1fb19220$> <1100271071.1109.38.camel@jzny.localdomain> <1100307886.1110.20.camel@jzny.localdomain> <> <009a01c4c934$99cf7990$020aa8c0@wwm1> <>
Organization: ZNYX Networks
Message-Id: <1100381538.2212.914.camel@jzny.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2
Date: Sat, 13 Nov 2004 16:33:39 -0500
X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/13/2004 01:37:05 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/13/2004 01:37:24 PM, Serialize complete at 11/13/2004 01:37:24 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Content-Transfer-Encoding: 7bit
Cc: "Khosravi, Hormuzd M" <>, Avri Doria <>, Dong Ligang <>,, Patrick Droz <>, "(Ram Gopal )" <>,, Weiming Wang <>, 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: 92df29fa99cf13e554b84c8374345c17
Content-Transfer-Encoding: 7bit

On Fri, 2004-11-12 at 23:21, Joel M. Halpern wrote:
> Sorry, I missed something.
> I believe that the protocol will have to define the encoding for all data, 
> in such a fashion that any data types (including structures) describable in 
> the model can be represented in well defined ways.

Would you say that an ID is a coherent description of a data type at
a given hierachy level? I.e as someone who knows the schema/template for
a LFB I should be able to tell with 100% certainty how to decode data if
you gave me the hierachy level and the ID (assuming the ID exists in the
template), No?

> Given such a definition, and given that the CE and FE both know the 
> definition of the data, then it can be processed.
> There are actually cases where the CE may not understand part of the data 
> that he is being handed.  If the structure being returned is actually a 
> subclass, with additional fields, of that understood by the CE.  However, 
> this actually works:
> 1) The CE will be able to parse all the fields he understands
> 2) The CE will have to ignore any fields he can not understand.  Note that 
> he has to ignore them if they have no type / field ID tagging or if it has 
> type and field ID tagging, since he has no idea what those fields mean anyway.


> The one implication of this is that the encoding for structures and arrays 
> must ALWAYS have a length.
> As far as I can tell, tables, or tables within tables, do not change this 
> with regard to field identification.  With regard to subscripts, there is 
> room to discuss.

I think every time you start encoding you need a lenght and some path ID
which says "btw, here starts foo1 which is of  length X"..
And within foo1 anytime you have anything thats of variable size such as
a string or array or cells that may reference variable sized entities
then you need again those two things { ID, length} 
If you assume these rules then you can pack data effeciently.
Sorry for jumping into encoding - it just seems that effective encoding
requires some deviation from the clean series-of-IDs approach.

> Given a field foo in the LFB which has ID 2, and is a structure with fields 
> bar (id 1), bas (id 2), and bat (id 3), where bas is a structure with field 
> cab (id 1), cac (id 2) and cad (id 3), then:
> if I want to reference cac I need the path 2.2.2 somewhere.
> if I want to reference bas, I need the path 2.2 somewhere, and I do not 
> need the id 2 of cac inside the representation of bas.
> if I want the whole field foo, I need the path 2, and I do not need the ids 
> for any of the contained fields.


I am gonna delete the rest of the discussion on content stuff. Can we
get some agreement on this basic stuff first?

Note - I still see the queries and deleted using the series of 32 bit
IDs to create a path.


Forces-protocol mailing list