Re: question on get the whole FE object LFB?

The CE simply asks for the table1 (or the whole LFB, or whatever.)
If the FE sends back a FULLDATA TLV encoding then 
the CE knows that all optional fields are present 
and all tables are dense.  The FULLDATA encoding does include the table length.
If the array is sparse, or there are optional 
fields missing (for example if t2 is optional, 
and not present in all elements, then the FE MUST 
use the SPARSEDATA encoding.  And the sparsedata 
encoding includes the indexes / ids, so the CE 
can properly parse the whole thing.

Yours,
Joel

At 11:39 PM 9/21/2006, Jia Fenggen wrote:
>I am afraid you have probably misunderstand what 
>i am complaining about,for example,the LFB  foo 
>have the following attributes defined:
>   foo1, type u32, ID = 1
>   table1: type array, ID = 2
>           elements are:
>           t1, type u32, ID = 1
>           t2, type u32, ID = 2
>   foo2,type u32,ID=3
>   table2: type array, ID = 4
>           elements are:
>           j1, type u32, ID = 1
>           j2, type u32, ID = 2
>
>table1 and table are variable arrays,let's take 
>that in the instance of LFB foo,table1 has 3 
>rows and table 2 has 4 rows.if we encoding this 
>LFB in FULLDATA,then because CE has no knowledge 
>of the current rows of table1 and table2,then it 
>can't decide how to get foo2 value,what do you think?
>Yours,Fenggen
>
>>From: "Joel M. Halpern" <[email protected]>
>>Reply-To: "Joel M. Halpern" <[email protected]>
>>To: [email protected]
>>Subject: Re: question on get the whole FE object LFB?
>>Date: Thu, 21 Sep 2006 23:27:12 -0400
>>
>>I believe you are partially correct.
>>That is, as you observe, a FULLDATA can only be 
>>used if all optional data elements are present.
>>This means that if all such elements are 
>>present, then a FULLDATA can be used for the 
>>response.  It is up to the FE to check this condition.
>>If not all optional elements are present, then 
>>the SPARSEDATA encoding is used.  That is what 
>>the SPARSEDATA encoding is for.
>>This avoids having to introduce multiple 
>>Path-data-TLVs in response to a single 
>>Path-data-TLV in a request.  It thereby 
>>preserves the semantic information that what is 
>>being returned is the whole LFB, while 
>>indicating which fields are present or absent.
>>
>>So, the example is legal.  If we have a chance 
>>to update this, we should probably note that it 
>>is only legitimate if all optional fields in the FE Object are present.
>>
>>Yours,
>>Joel M. Halpern
>>
>>At 11:06 PM 9/21/2006, Jia Fenggen wrote:
>>>In draft-forces-portocol-8.txt Appendix D use 
>>>case section,the 19 use case is about how to 
>>>get a whole LFB,it uses FE object LFB as a 
>>>example: Get a whole LFB (all its attributes, etc.).
>>>
>>>For example:  at startup a CE might well want the entire FE
>>>           OBJECT LFB.  So, in a request targeted at class 1, instance
>>>           1, one might find:
>>>
>>>
>>>
>>>   operation = GET-TLV
>>>           Path-data-TLV
>>>                   flags = 0  IDCount = 0
>>>
>>>   result:
>>>   operation = GET-RESPONSE-TLV
>>>           Path-data-TLV
>>>                   flags = 0  IDCount = 0
>>>                   FULLDATA encoding of the FE Object LFB
>>>here it uses FULLDATA to encoding the FE 
>>>Object LFB,I think it's probably not 
>>>correct,in FE Object LFB we have several 
>>>variable arrays and when encoding in 
>>>FULLDATA,the CE may not figure out what is the 
>>>ending of a array,I think we could use flat 
>>>Path data encoding or Nested Path data encoding to solve this like follows:
>>
>>... example details delete for length.
>
>_________________________________________________________________
>Ãâ·ÑÏÂÔØ MSN Explorer:   http://explorer.msn.com/lccn/
>