Re: FW: HTTP digest and RADIUS; new version of the Sterman draft

[Bernard Aboba <aboba@internaut.com>]

>   ... new VSA-style attributes with sub-types can be ignored by
> servers that don't understand them.  Provisions for this behaviour are
> already in the RFC's.  This makes adding new attributes easy, whatever
> their internal format.

The issue isn't just for receivers.  It is also for servers *sending* the
attributes.

> attributes is irrelevant to anyone not implementing support for them.

In general, the server does not need to understand attributes that it
sends, although the NAS does need to understand those it receives.
If the server is sending an attribute it doesn't understand, why should
the server require code changes?

While one could argue that the server could just create a "String" type,
the reality is that many RADIUS implementations don't support entering
arbitrary binary data into "String" attribute types.

> I don't see anyone here trying to create a data definition language
> for RADIUS.  That's a bit much.  The only debate I've seen so far is
> about the ability to have VSA-style sub-types in new attributes.

In Diameter, grouped AVPs are not allowed except where the AVPs being
grouped have some relationship to each other.  So is the issue really
grouping, or is it the need for new types (such as a 128-bit IPv6 address
type).  If the former, do we understand why the tagging approach proposed
in RFC 2867 and 2868 won't work?

> I agree that this will be sufficient for many situations.

Do we have concrete examples of where this will *not* work?

BTW, it's important in this discussion to distinguish between "tagging",
grouped AVPs and additional datatype proposals.  Each of these approaches
has quite different implications.

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