Re: Proposed Resolution to Issue 198: Attribute Concatenation/Splitting

[Barney Wolff <barney@databus.com>]

On Fri, Sep 29, 2006 at 01:30:12PM -0700, Bernard Aboba wrote:
> How about this?
> 
>   Tag
> 
>      The Tag field is used to identify the filter rule that is
>      represented; the length of the Tag field is one octet and it MUST
>      always be present.  The Tag field value MUST be in the range
>      0x01-0x3F; NAS-Filter-Rule attributes with a Tag field value of
>      0x00 are ignored upon receipt.
> 
>      Where a single filter rule is less than or equal to 252 octets in
>      length, it MUST be encoded with a tag value of '0' (0x30) and MUST
>      NOT be split between multiple NAS-Filter-Rule attributes.  Where a
>      single filter rule is split into multiple NAS-Filter-Rule
>      attributes, the attributes SHOULD be sent consecutively, without
>      intervening attributes with another Tag field value.  On receipt,
>      attributes with a Tag value of '0' (0x30) MUST NOT be concatenated
>      to form a single filter rule.
> 
>      Where a single filter rule exceeds 252 octets in length, the rule
>      MUST be encoded across multiple NAS-Filter-Rule attributes, each
>      with the same Tag value which MUST NOT be '0' (0x30).  Tag values
>      MUST be unique for each filter rule present in a RADIUS packet
>      with the exception of a Tag value of '0' (0x30), which may be used
>      in multiple attributes, each describing a single filter rule.

I hate to be stubborn, but unless it says "attributes MUST be sent
consecutively" the receiver cannot count on it, so the SHOULD is
useless.  Can anybody think of a reason for a sender to interleave
parts of attributes, other than actual malice?

-- 
Barney Wolff         I never met a computer I didn't like.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>