Re: Preferences and Requirements Options (was Re: Proposal to resolve remaining CARD issues)

Eunsoo Shim wrote:

>>>The two sub-options have different formats as well as different
>>>      
>>>
>semantics.
>  
>
>>>Two separately defined sub-options are simpler in usage and
>>>encoding/decoding, I think.
>>>
>>>      
>>>
>>Can you explain how having two sets of parsing code is simpler than having
>>one?
>>
>>    
>>
>
>The Requirements sub-option should contain a list of AVP while the
>Preferences sub-option should contain only a list of attribute IDs. That is,
>they have different formats. By knowing the type of sub-option from the
>sub-option header, the receiver knows what format to be expected.
>
>Also by putting all the Requirements separately from the Preferences, the
>receiver can get the Requirements at once without having to figure out
>whether each filter is for Requirements or Preferences.
>
>An alternative suggested in the mailing list to merge the two sub-options
>was putting a empty value for the AVP to indicate the AVP was for
>Preferences. To do this, each AVP for Preferences should have the length
>field as well which indicates always zero. It is waste of bandwidth. Reading
>the length field is waste of the receiver resources (time and power). In the
>end, the receiver should logically separate Requirements from Preferences
>from the merged filter. So from the viewpoint of implementers, merging the
>two sub-options into a single sub-option requires another step to separte
>them in the receiver side.
>
>Logically the two filters are separte to the sender as well as the receiver.
>Having them separated physically is clearer for both of the sender and the
>receiver.
>
>
>Eunsoo
>
>
>  
>

I agree with Eunsoo here, that also the logical function should be taken 
into consideration. How to
process payload of the sub-option is clear already after processing the 
sub-option type, whereas
when using one sub-option for both functions, individual AVPs need to be 
checked. In the latter
case, the length should not be 0x00 but 0x03 in case of just 
transmitting Attributes...
Furthermore, should we allow then also a "mixed" approach, where this 
merged sub-option
can convey Attribute-Value-Pairs for CAR filtering together with only 
Attributes for
capbility filtering...? I think then ist really starts to get complex 
without getting any benefit.

I propose to keep going for the 2 separate sub-options. However, in case 
we drop also the
AVP Length fields in a Preferences sub-option for bandwidth 
optimization, we have the
same problem as we have for the L2-ID, which is related to "length 
without padding" and
"length with padding". For a solution I propose the following: Just list 
Attribute values (each
has 16 bit). In case (# of attributes) mod 2 = 0, fine, otherwise attach 
Attribute value
0x00 for padding. Value = 0x00 should then not be used for capabilities.

What do you think?

marco