RE: RADIUS Design Guidelines

["Nelson, David" <dnelson@enterasys.com>]

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?

> The limitation of using tags to group attributes in
> conjunction w/this traditional method is that only one XL 
> attribute of a given (extended) type can belong to a group.

Yes.

> If this is a serious problem, then some method of distinguishing
> the beginning of a new attribute from the middle of the previous
> one would be required.

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


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