[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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. 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.
> 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.
David B. Nelson
Wireless & AAA Architect, Office of the CTO
Enterasys Networks, Inc.
50 Minuteman Road
Andover, MA 01810-1008
Phone: (978) 684-1330
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.