RE: RADIUS Design Guidelines

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Nelson, David <> scribbled on Monday, August 28, 2006 10:28 AM:

> Glen Zorn writes...
> 
>> We already know how to send & receive XL attributes, via in-order
>> fragmentation, transmission & concatenation.  There is no need to use
>> tags for this.
> 
> Yes, but doesn't this depend on the per-attribute textual definition?
> What I mean to say is that for some attributes there can be only one
> "logical" instance in a RADIUS message, and any additional instances
> MUST be continuations of the first.  For other attributes, having
> multiple instances in messages is acceptable, and there is no
> continuation ever required (or allowed).  What happens if there is an
> attribute that can have multiple instances *and* can have some of
> them continue over multiple attributes?   Don't we need the tag
> (grouping) to      
> indicate which are separate instances and which are continuations of
> an instance? 

Yup, you're right.

...

> 
> If this is a serious problem, could we simply use two tag fields, one
> to mark grouping for "data structuring" and another to mark grouping
> for "continuation"?  

That's certainly one way to do it, & simple.  Another (more compact but
less simple) way would be to give away the high-order bit of the tag to
an "Attribute start flag"; this only allows 128 frags/attr (around 32K
max attribute length) however.

Hope this helps,

~gwz

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