[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Proposed resolution to guidelines document
How about adding some text to Section 2.1.3:
" There may be situations where complex attributes are beneficial,
because they reduce complexity in the non-RADIUS systems.
Unfortunately, there are no "hard and fast" rules for where the
complexity would best be located. Each situation has to be decided on a
[BA] Is this referring to the "opaque data" case? Elsewhere in 2.1.3 it
talks about these attribute being defined as type "String":
If the RADIUS Server simply passes the contents of an attribute to
some non-RADIUS portion of the network, then the data is opaque, and
SHOULD be defined to be of type String. A concrete way of judging
this requirement is whether or not the attribute definition in the
RADIUS document contains delineated fields for sub-parts of the data.
If those fields need to be delineated in RADIUS, then the data is not
opaque, and it SHOULD be separated into individual RADIUS attributes.
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.