Standardised JSON VP list format

[Brian Candler]

On Tue, Nov 08, 2011 at 01:32:12PM +0100, Arran Cudbard-Bell wrote:
>    I'm proposing the following JSON structures for VP lists being sent
>    from and parsed by FreeRADIUS. If anyone has any suggestions regarding
>    other fields they'd like to see included, let me know.

I think we should keep it simple, and I would also like to see it
symmetrical for data in and out of a module.

If a regular FreeRadius output has

    Service-Type = Framed-User
    Framed-Protocol = PPP

then a starting point would be:

#1
   {"Service-Type": "Framed-User",
    "Framed-Protocol": "PPP"}

That is, I don't see a need to include an explicit Type, since the receiver
will presumably have a dictionary; and the value can be whatever format is
used when FreeRadius normally inputs or outputs a string of that type (e.g.
radclient, rlm_sql etc)

Then there is the requirement for keeping ordering between repeated
attributes.  Simple options like

#2
   [{"Service-Type": "Framed-User"},
    {"Framed-Protocol": "PPP"},
    {"Reply-Message": "Foo"},
    {"Reply-Message": "Bar"}]

#3
   [["Service-Type": "Framed-User"],
    ["Framed-Protocol": "PPP"],
    ["Reply-Message": "Foo"],
    ["Reply-Message": "Bar"]]

are direct but inconvenient when you want to look up the value for a
particular attribute.  So I would go as you suggest:

#4
   {"Service-Type":["Framed-User"],
    "Framed-Protocol":["PPP"],
    "Reply-Message":["Foo","Bar"]}

Aside: it would be convenient to permit modules which generate this format
to be allowed to omit the [array] for single-valued attributes.  But the
above would be the normalised form which FreeRadius itself would always
generate.

>    Inbound (response):

RADIUS packets themselves of course don't include "+=" or ":=" or "=", but
I guess this format needs to work for internal communication between modules
and FR.

So there are several options I can think of:

#5 - Non-extensible
  {"Service-Type": [{"+=": "Framed-User"}],
   "Framed-Protocol": [{":=": "PPP"}]},
   "Reply-Message": [{"+=": "Foo"}, {"+=": "Bar"}]}

#6 - Verbose but extensible
  {"Service-Type": [{"op":"+=","value":"Framed-User"}],
   "Framed-Protocol": [{"op":":=","value":"PPP"}]}
   "Reply-Message": [{"op":"+=","value":"Foo"}, {"op":"+=","value":"Bar"}]}

5 and 6 are butt-ugly and should be discounted for that reason alone.

#7 - Like #3 with third value. Missing third value implies "+="

  [["Service-Type", "Framed-User", "+="],
   ["Framed-Protocol", "PPP", ":="],
   ["Reply-Message", "Foo", "+="],
   ["Reply-Message", "Bar", "+="]]

Easy to use when generating responses, but I hate the asymmetry with #4.

So how about including the update operator in the label?

#8
  {"Service-Type+=": "Framed-User",
   "Framed-Protocol:=": "PPP",
   "Reply-Message+=": ["Foo","Bar"]}

So basically, "+=" would always add (and is perhaps the default?), ":="
would always erase the list first and then add, and = would do nothing if
the attribute already exists.  And so

  {"Reply-Message:=",[]}

could be used to remove an attribute; perhaps also value null could do that.

Finally, I'd also like to be able to update request/control/reply lists in
one go, and the simplest way I can think of is:

#9
  {"request:Huntgroup-Name:=", "Foo",
   "reply:Framed-Protocol+=", "PPP"}

The list: prefix would be optional and could be implied from context
normally (e.g. default to request: list for queries and reply: for
responses)

Final idea: if you want the labels to be easier to parse, split them on a
character which is unlikely to occur.

#10
  {"request|Huntgroup-Name|:=", "Foo",
   "reply|Framed-Protocol|+=", "PPP"}

Just a few random thoughts :-)

Regards,

Brian.