[radext] #31: Section 2.1

["radext issue tracker" <trac@tools.ietf.org>]

#31: Section 2.1
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@â            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  minor                      |   Milestone:  milestone1
Component:  design                     |     Version:  1.0       
 Severity:  Submitted WG Document      |    Keywords:            
---------------------------------------+------------------------------------
 All other data formats are defined to be "complex data types", and
    are NOT RECOMMENDED for normal use.  Nested attributes, or attributes
    grouped via methods other than defined in [RFC2868] do not qualify as
    "basic data types", and SHOULD NOT be used.

    There may be situations where complex attributes are acceptable
    because they reduce complexity in non-RADIUS systems, or because
    leveraging the basic data types would be awkward.  Unfortunately,
    there are no "hard and fast" rules for where the complexity would
    best be located.  Each situation has to be decided on a case-by-case
    basis.  The cost-benefit trade-off may result in a "complex data
    type" being defined in RADIUS, as discussed in Appendix B.  When this
    is done, an explanation SHOULD be offered as to why the complex data
    type was used.

 [BA] The first paragraph could be mis-construed as prohibiting grouping
 mechanisms such as the Extended Attributes approach.

 Recommended replacement:

    All other data formats (including nested attributes) are defined
    to be "complex data types", and are NOT RECOMMENDED for normal
    use.  Complex data types MAY be used in situations where they
    reduce complexity in non-RADIUS systems, or where using
    the basic data types would be awkward (such as where grouping
    would be required in order to link related attributes).  Since
    there are no "hard and fast" rules for where complexity is best
    located, each situation has to be decided on a case-by-case
    basis.  Examples of this tradeoff are discussed in Appendix B.
    Where a complex data type is selected, an explanation SHOULD be
    offered as to why this was necessary.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/31>
radext <http://tools.ietf.org/radext/>


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