Standardised JSON VP list format

[Alan DeKok]

Brian Candler wrote:
> As for tags, the first option which springs to mind is to put them in the
> attribute label, as they are in FreeRadius today.

  I'd really like to avoid that.  It makes it much more difficult to
handle attributes.

> However with tags, the update operators don't behave how I'd expect.  If I
> write
> 
>     Tunnel-Server-Endpoint:0 := 1.2.3.4
>     Tunnel-Server-Endpoint:1 := 5.6.7.8
> 
> then the second := erases all previous instances of Tunnel-Server-Endpoint. 
> The tag behaves not as part of the attribute, but as part of the value
> (which in fact it is).

  Yes, that is a problem.

> A more convenient way to handle tags would be as object keys:
> 
> {
>   "Tunnel-Server-Endpoint": {"0"=>"1.2.3.4", "1"=>"5.6.7.8"}
> }

  That might be better.

> Final point: if you are returning a bundle of attributes, currently these
> are always *merged* into the reply packet.  You can delete individual
> attributes using -= or !* operators, but there is no way to say "replace the
> entire reply list built so far" without invoking something like attr_filter
> in unlang.

  Yeah.  It would be nice to have some kind of language describing how
to process the two lists (current, new).  But that's hard.

> This is no worse for rlm_rest than we have today, but I'd really
> like some way to return maybe a magic attribute which either deletes all
> attributes, or all attributes apart from those listed in the reply, or
> triggers a specific entry in rlm_attr_filter.
> 
> But this is going outside the realm of JSON formatting.

  Yes.   Suggest a syntax...

  Alan DeKok.