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

"Weiming Wang" <> Sat, 13 November 2004 04:04 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id XAA27049 for <>; Fri, 12 Nov 2004 23:04:44 -0500 (EST)
Received: from ([]) by with esmtp (Exim 4.33) id 1CSpB6-0001cP-Hf for; Fri, 12 Nov 2004 23:06:20 -0500
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1CSp4C-0001mx-Oc; Fri, 12 Nov 2004 22:59:12 -0500
Received: from ([] by with esmtp (Exim 4.32) id 1CSox7-0000Sv-3c for; Fri, 12 Nov 2004 22:51:53 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id WAA26201 for <>; Fri, 12 Nov 2004 22:51:50 -0500 (EST)
Received: from [] (helo= by with smtp (Exim 4.33) id 1CSoya-0000zl-SY for; Fri, 12 Nov 2004 22:53:26 -0500
Received: from [] by with StormMail ESMTP id 58110.341813895; Sat, 13 Nov 2004 12:15:32 +0800 (CST)
Received: from wwm1 (unverified []) by (Rockliffe SMTPRA 6.0.11) with ESMTP id <>; Sat, 13 Nov 2004 11:50:14 +0800
Message-ID: <009a01c4c934$99cf7990$020aa8c0@wwm1>
From: Weiming Wang <>
To:, "Joel M. Halpern" <>
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> <>
Subject: Re: [Fwd: [Forces-protocol] Presentation of the options forLFB-level multicast]
Date: Sat, 13 Nov 2004 11:55:14 +0800
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Cc: "Khosravi, Hormuzd M" <>, "(Ram Gopal )" <>, Avri Doria <>,, Patrick Droz <>,, Dong Ligang <>, 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.4 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c


We'v seen more clearly our difference now after we begin to consider the data
encoding, therefore it's very good to associate our previous discussion with
followed data encoding.

----- Original Message -----
From: "Joel M. Halpern" <>

> I may be missing something, but when I consider likely encodings of data,
> there are two aspects.  There are element identifiers (top level attribute,
> element of struct, etc) and there are subscripts.
> Now, for nested structs, or structs within tables, or any other cases,
> there is no need to encode the identifiers for the fields in the
> data.  Knowing the starting point of the data, and the type of that
> starting point, and the encoding rules, should allow one to decode the
> elements without needing either internal type identifiers or internal
> element identifiers.  Variable length elements (strings, arrays) do need
> lengths.
One thing I just want to strenthen that is in my previous post is,  if the field
IDs and others are not allowed in the data field, we will have to strictly
define all individual data format (including its data PDU and appearing
sequence) for all attributes of all LFBs, which is really a horrible thing to
do. By allowing field IDs in data, we only need to define the individual field
ID actual values, which I think is much simpler and FE model can do well.


> When an entire array is being shipped, if the elements have subscripts
> (which I want) then it is indeed necessary to include the subscripts of
> each element with that element.  There are multiple ways to adress this,
> but none of them involve putting the field identifiers into the data.
> Yours,
> Joel
> PS: If one is going to use a verbose TLV-like encoding of the data, one may
> end up encoding the types in the data or the field identifiers.  But this
> is fundamentally redundant information.

Forces-protocol mailing list