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

"Joel M. Halpern" <joel@stevecrocker.com> Sat, 13 November 2004 03:19 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 WAA24842 for <forces-protocol-web-archive@ietf.org>; Fri, 12 Nov 2004 22:19:22 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSoTB-0008ES-RA for forces-protocol-web-archive@ietf.org; Fri, 12 Nov 2004 22:20:58 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSoQS-0000ZM-W3; Fri, 12 Nov 2004 22:18:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSoOs-0008Cq-36 for forces-protocol@megatron.ietf.org; Fri, 12 Nov 2004 22:16:30 -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 WAA24688 for <forces-protocol@ietf.org>; Fri, 12 Nov 2004 22:16:27 -0500 (EST)
Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSoQL-00086L-VK for forces-protocol@ietf.org; Fri, 12 Nov 2004 22:18:03 -0500
Received: from [69.170.19.208] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7937681; Fri, 12 Nov 2004 22:16:21 -0500
Message-Id: <6.1.2.0.0.20041112220931.03c89ec0@localhost>
X-Sender: joel@stevecrocker.com@localhost
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Fri, 12 Nov 2004 22:16:09 -0500
To: hadi@znyx.com, "Wang,Weiming" <wmwang@mail.hzic.edu.cn>
From: "Joel M. Halpern" <joel@stevecrocker.com>
Subject: Re: [Fwd: [Forces-protocol] Presentation of the options forLFB-level multicast]
In-Reply-To: <1100307886.1110.20.camel@jzny.localdomain>
References: <4189F776.4080306@zurich.ibm.com> <1099700691.1038.2.camel@jzny.localdomain> <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>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>, "\(Ram Gopal \)" <ram.gopal@nokia.com>, Avri Doria <avri@acm.org>, forces-protocol@ietf.org, Patrick Droz <dro@zurich.ibm.com>, David.Putzolu@intel.com, Dong Ligang <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
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.1 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d

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.

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
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol