RE: : Reconciling Radius/Diameter SIP application

Option b) is cleaner because it requires less parsing work by AAA server.

Regarding the following comment:

> handle everything 
> as much as 
> > possible by taking all text from the SIP syntax and putting 
> it blindly 
> > into an AVP...

Wolfgang's original document did that for all the attributes (using
subtypes) which could have been handled by both RADIUS and Diameter. Lets
not go there again.


> > 
> >> 11- We noticed that most of the HTTP Digest directives 
> contain just a
> >> single token. However, the "qop" directive may contain a 
> >> comma-separated collection of tokens. For instance, 
> >> qop="auth,auth-int". The question is how do encode these 
> tokens in the 
> >> Digest-Qop attribute. The options are:
> >>
> >> a) Treat the whole thing as one token and put it into the attribute
> >> value.
> >> b) Each token is an attribute, thus, there might be multiple 
> >> Digest-Qop attributes in a particular Radius/Diameter message.
> >>
> >> We think that option b) is cleaner. Particularly it will be easier 
> >> for
> >> the Diameter/Radius client to encode different values in different 
> >> attributes.
> > 
> > 
> > I think option a) is cleaner, although I don't care enough 
> to think it 
> > should be a showstopper. But here's my reasoning: avoid unnecessary 
> > mapping work that the client needs to do; handle everything 
> as much as 
> > possible by taking all text from the SIP syntax and putting 
> it blindly 
> > into an AVP...
> > 
> 
> I don't care either. I just thought we shouldn't put too much work to 
> the Diameter/Radius server about how to encode Digest directives. 
> Approach a requires the Diameter/Radius server to be able to encode 
> "auth", "aut-int", "auth,auth-int", and use it appropriately. If the 
> number of tokens is just two, then any approach is feasible.
> 
> - Miguel
> 
> 
> > --Jari
> 
> -- 
> Miguel A. Garcia           tel:+358-50-4804586
> Nokia Research Center      Helsinki, Finland
>