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

Jamal Hadi Salim <hadi@znyx.com> Sat, 13 November 2004 21:59 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 QAA03163 for <forces-protocol-web-archive@ietf.org>; Sat, 13 Nov 2004 16:59:44 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CT5xZ-0004ka-1C for forces-protocol-web-archive@ietf.org; Sat, 13 Nov 2004 17:01:29 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CT5ks-0004Ji-HH; Sat, 13 Nov 2004 16:48:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CT5Wc-000281-4D for forces-protocol@megatron.ietf.org; Sat, 13 Nov 2004 16:33:39 -0500
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 QAA01683 for <forces-protocol@ietf.org>; Sat, 13 Nov 2004 16:33:36 -0500 (EST)
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 1CT5YG-0003Vz-LT for forces-protocol@ietf.org; Sat, 13 Nov 2004 16:35:21 -0500
Received: from localhost ([208.2.156.2]) by lotus.znyx.com (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 <hadi@znyx.com>
To: "Joel M. Halpern" <joel@stevecrocker.com>
In-Reply-To: <6.1.2.0.0.20041112230835.03f0b0f0@localhost>
References: <4189F776.4080306@zurich.ibm.com> <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$845c21d2@Necom.hzic.edu.cn> <1099911200.2169.29.camel@jzny.localdomain> <134f01c4c585$216584c0$845c21d2@Necom.hzic.edu.cn> <4191299F.4020809@zurich.ibm.com> <142a01c4c6d6$13569980$845c21d2@Necom.hzic.edu.cn> <1100100893.2210.24.camel@jzny.localdomain> <14fc01c4c79f$75231f20$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20041111091015.03bafec0@localhost> <155001c4c8c0$5eb73ec0$845c21d2@Necom.hzic.edu.cn> <1100269665.1106.30.camel@jzny.localdomain> <156501c4c8c5$1fb19220$845c21d2@Necom.hzic.edu.cn> <1100271071.1109.38.camel@jzny.localdomain> <1100307886.1110.20.camel@jzny.localdomain> <6.1.2.0.0.20041112220931.03c89ec0@localhost> <009a01c4c934$99cf7990$020aa8c0@wwm1> <6.1.2.0.0.20041112230835.03f0b0f0@localhost>
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" <hormuzd.m.khosravi@intel.com>, Avri Doria <avri@acm.org>, Dong Ligang <donglg@mail.hzic.edu.cn>, forces-protocol@ietf.org, Patrick Droz <dro@zurich.ibm.com>, "(Ram Gopal )" <ram.gopal@nokia.com>, David.Putzolu@intel.com, Weiming Wang <wmwang@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: 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.
> 

nod.

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

nod

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.

cheers,
jamal


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