Re: [Forces-protocol] Feedback: Section 6.4

----- Original Message -----
From: "Joel M. Halpern" <jhalpern@megisto.com>
Subject: Re: [Forces-protocol] Feedback: Section 6.4

> Remember that there may be structures inside structures, or arrays inside
> structures inside arrays inside structures, ...
>
> Hence, a path is a sequence of identifiers,
I suppose you are proposing the 'path' is variable in length, which  I think may
be not the original idea of a path as a 32 bit index for table only.
If it is, i think the idea mathces more to what I proposed. Definitely, I think
the first ID appearing in the sequence is the attribute ID.

>each of which is either a
> subscript or an element identifier within the containing scope (initially
> the LFB classs definition, then progressive the structures selected by the
> earlier path elements.
> For simplicity, I suggest we make all the identifiers 32 bits.
I have no doubt to agree with this. Just need to calrify that a path is more
than 32 bits long, or there will be not enough bits.

Thank you.
Weiming

>
> Yours,
> Joel
>
> At 11:17 AM 10/26/2004 +0800, Wang,Weiming wrote:
> > > To point to first entry of datatable: 6,1
> >[Weiming]I'm glad to see this. It also means you'v agreed that the 'path'
> >includes one subsection  which is for attribute ID, right? Now the problem
is,
> >how many bits are you going to use for such ID, 8 bits or 16bits? I
> >suppose you
> >will not use a variable size for this ID. Whether the ID length is variable
or
> >not, we  then can both reasonably think the 'path' as composed of follows:
> >                 Path : = AttributeID  Index
> >  that really matches my idea. I also think  it mathces your idea too as
> >presented in your example here as 6.1, 6.2.3, etc.
> >
> >To summarize, what I proposed actually include two thoughts:
> >a) Attribute ID is necessary;
> >b) the attribute ID should appear in the protocol layer. The followed
> >Index can
> >be included in Data field, becaue not all attributes need Index (they may
only
> >have one entry).
>

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