RE: Capabilities: Summary

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

Further to my last comment...

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

Might I suggest one solution to this objection would be to create a
single new attribute called Required-Attribute, whose value is the
attribute ID of the required attribute.  Zero or more instances of
Required-Attribute would be allowed in Access-Challenge messages.



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