RE: Subtypes

[Avi Lior <avi@bridgewatersystems.com>]

> -----Original Message-----
> From: Nelson, David [mailto:dnelson@enterasys.com] 
> Sent: Monday, December 01, 2003 12:06 PM
> Cc: radiusext@ops.ietf.org
> Subject: RE: Subtypes
> 
> 
> Avi Lior writes...
> 
> > I would rather see a test that considers the following:
> > A) Are subcomponents of the attribute useful to intermediaries;
> > B) Should subcomponent be "promoted" because they are useful.
> > C) If a RADIUS server needs to parse the attributes, does it make 
> > sense to encode them using subTLVs. There could be other "tests" or 
> > guidelines.
> > 
> > If I wanted to be pendantic about the feedback I am getting on
> > this list; your X.500 MUST be encoded using separate attributes.
> 
> Fine.  I would not object to that approach. 

Which approach?
The approach of forcing an X.500 to be encoded using separate attributes. Or
the set of tests I defined above?


> My point was 
> that multi-part data entities that comprise a *single* entity 
> in a well-defined ASCII (UTF-8) syntax, such as FQDNs, are 
> perfectly "normal" as string-valued attribute content.  A 
> group of *related* data entities encoded in a similar fashion 
> is simply sub-types in disguise.  I agree
> that the distinction can be a fine one to attempt to codify, 
> however.   

Actully I will make a stronger statement: there is no distinction between
the two.  One man's garbage is another man's treasure;


> > Using my test we can decide what the best action to take on an
> > attribute by attribute basis.
> 
> Well, please forgive my directness, but your suggested rules 
> seem designed to justify existing implementation, for the 
> sake of convenience to the early adopters, rather than 
> focusing on good protocol design principles.  I understand 
> that this is also a somewhat subjective analysis -- but I 
> think it's one of those "I know it when I see it." sort of things.

Not for the sake of convenience to early adopters at all. But I think a
pragmatic approach to a problem.  BTW, my rules are not complete just
something I came up with on the fly - if that is the right approach lets
create a set of rules/guidelines that do make sense. 

But what is wrong with justifying existing implmentation for the sake of
convience to early adopters.  That should also be taken into account. no?
If the attribute as been in wide use and there is no good reason to change
it then lets not.  Doesn't that make common sense. 


> Regards,
>  
> Dave
>  
> David B. Nelson
> Wireless & AAA Architect, Office of the CTO
> Enterasys Networks, Inc.
> 50 Minuteman Road
> Andover, MA 01810-1008
> Phone: (978) 684-1330  
> E-mail: dnelson@enterasys.com
>  
> 
> 
> --
> 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/>