RE: Data Types defined in RFC 2865

["Dave Nelson" <d.b.nelson@comcast.net>]

Glen Zorn writes...

> So am I to understand that, despite the multitude of counterexamples
> and the lack of any explicit text even suggesting such in any RADIUS-
> related RFC, you are claiming that the name of the V field in the TLV
> construct denotes a formal data type (a thing apparently known only to
> some secret society holding the same "internally consistent belief 
> system" (thought police, anyone? ;-)?

Well, your previous posting claiming to be able to implement an advanced
server implementation that intuits the syntax of a data model from the data
stream itself notwithstanding, RADIUS *has* a formal, written data model.
Many implementations rely on it.  It's a very simple data model.

I think this extended discussion of what constitutes a "formal" definition
of a new data type in the data model constitutes "protocol lawyering", a
debate about form without any substance.

In seeking to debunk some of these data model additions, you are apparently
attempting to build a case for the precedence of using the RADIUS String
data type to contain non-self-describing data structures.  This has been a
point of debate in the RADEXT WG for several years.  The WG consensus is
captured in the Design Guidelines draft.  The String data type should be
used for actual strings, or for opaque blobs of binary data, for use in some
other protocol component, e.g. EAP.  There are specific exemptions to this
recommendation that are spelled out in the draft.



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