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

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