Re: question on get the whole FE object LFB?

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.