RE: : digest issue 11 closure (fwd)

Miguel Garcia writes...

> So the point I want to make is that, due to the lack of grouped
> attributes in RADIUS, you do need translation rules in RADIUS in order
> to generate the appropriate HTTP/SIP digest header.

Why in RADIUS?  IMHO, the RADIUS protocol engine should not have to
understand the SIP server functions.  It would seem to me that this
function belongs in the "glue layer" code between the SIP server and the
RADIUS client.

While I agree that grouped AVPs are a nice feature of Diameter, they
don't in and of themselves obviate the need for "glue code" between the
RADIUS client and another layer that is using its services.  I suppose
that statement makes some assumptions on where you draw component
boundaries in your implementation, but my assumption is that a RADIUS
client implements the RADIUS protocol, and that various interface layers
marshal the attributes in and out of other protocol formats.

I think the *goal* of having "exception-less" RADIUS/Diameter gateways
is a good one.  If the gateway is always part of the Diameter [home]
server implementation, then it doesn't matter so much.  On the other
hand, if the gateway is a standalone function, or part of a RADIUS proxy
or Diameter proxy, then it may be significant issue.  The issue, of
course, is version synchronization.  If you add a new feature in your
RADIUS client and Diameter server, it might be nice to not need to also
version upgrade all of the gateways that exist somewhere in the proxy
server chain.