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

["Joel M. Halpern" <[e-mail]>]

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


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.


With regard to subscripts and content based addressing, things are more 
complicated.  In the path, we need the indication at each table of whether 
indexing is occuring, and if so which subscript or content field is being 
used.  That is type based information which can go in the path.
The question is where the subscripts or content values go.
They are going to have to have their won TLVs somewhere.  They can go 
inside the path TLV, although that will complicate the structure of the 
path TLV.
They can be siblings of the path and data TLV.
Or they can somehow be in the data TLV.
Given the structuring requirements I believe it will be simpler to make 
them (the element value selection TLVs) siblings of the path and data TLVs 
within the overall path-data structure.  I can believe that there exists a 
clean structure for putting them in the data itself.  And the placement of 
this is much less important to me than the placement of the information 
which tells me what syntax of subscripts and what syntax and semantics of 
final data I am using, namely the path information.

Yours,
Joel M. Halpern

At 10:55 PM 11/12/2004, Weiming Wang wrote:
>Joel,
>
>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" <[e-mail]>
>
> > 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.
>
>Cheers,
>Weiming
>
> >
> > 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/forces-protocol