RE: RADEXT charter, Take 8

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

Wolfgang Beck Writes...

> If this does not translate into 'string attributes must not be
> structured', I can live with it.

What is a structured string?  It could be:

     - XML
     - HTTP
     - X.500 directory name
     - X.509 certificate
     - A sonnet
     - A limerick
     - The collected works of William Shakespeare

A structured string could also be a binary protocol encoding (such as a
TLV 3-tuple) represented as printable ASCII (or UTF-8) characters.

I may be confusing your posts with someone else, but I seem to recall
that you were advocating one or more of the above definitions of
structured string.  

*If* the intent of structured strings is to "hide" multi-level (nested)
sub-attributes in a "bag of undistinguished octets", only to later open
that bag and effectively "get around" the requirements for compatibility
with existing RADIUS RFCs and recommended attribute formats, then you
equally know my opinion about this!  :-)  *If* we are ever to embrace
complex, multi-level sub-attributes, we need to do it explicitly,
following the process outlined in the draft charter (Take 8).

> You know my opinion about this.

I think I do.  But maybe you could refresh my memory.  Basically, your
position is that "flat" RADIUS TLV attributes are "bad".  They cramp
one's creativity, flexibility and the ability to arbitrarily "group"
data items, as you could in a C-language data structure or as in an
SMIv2 based MIB.  Is that correct?

-- Dave









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

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