RE: Capabilities: Summary

["Nelson, David" <dnelson@enterasys.com>]

Alan DeKok writes...

> Once an implementation supports that, any server can challenge the
> client with "hints", as described above.  A possible workflow is:
> 
>   C -> S: Access-Request
> 		User-Name = foo
> 		User-Password = bar
> 		Capability = yes
>   S -> C: Access-Challenge
> 		Require-Location = yes
> 		State = abcd
>   C -> S: Access-Request
> 		User-Name = foo
> 		User-Password = bar
> 		Capability = yes
> 		location = "moe's tavern"
> 		State = abcd

This works well, for the specific case of GEOPRIV.

For the general case of a server requiring a client to support
<arbitrary-attribute>, this method would require a new attribute called
Require-<arbitrary-attribute> for every value of <arbitrary-attribute>
of interest.  Surely this would lead to attribute bloat.


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