Standardised JSON VP list format

[Arran Cudbard-Bell]

On 8 Nov 2011, at 14:18, Ruslan Shevchenko wrote:

> 1.  It is also necessory to standartize representation of  primitive
> values, i.e..
> 
> a) IP4, IP6   [variants: string which can be passet to net_pton]
> b) IP6Prefix  [variant   ???  -- some standart text representation]
> c) Mac address [ variant: canonical IEE 802  string representation,
> i.e.  http://en.wikipedia.org/wiki/IEEE_802 ]
> d) Octets   [ base64  string ? ]
> e) IFID  [base64 ?  hex string ?, integer ?]

We only really need to standardise primitives that are interpreted by FreeRADIUS directly.
The format should be whatever FreeRADIUS can interpret or encode as RADIUS attributes.

a) IPv4 Standard dotted quad without CIDR suffix
b) IPv6 Suggestions?
c) IPv6-Prefix Suggestions?
d) MAC-Address - User/Application defined (not used internally by FreeRADIUS) - Most likely a JSON string though, as I don't believe JSON supports 64bit integers...
e) Octets - These are currently encoded as a hex string by vp_prints, but BASE64 would be more efficient. It should be possible to add support for 'automagical' BASE64 parsing for the response, i.e. the server can determine if it's hexits or BASE64. For clarity/debugging I'm still leaning towards hexits in the request. But good point, i'll look into this...
f) IFID( do you mean ifIndex?) Integer or String, FreeRADIUS does the conversion automatically


> ) Note: The outbound request will only use attributes from the request
> list. If you think attributes should be ) included from multiple
> lists, please explain why.
> 
> I.e. this is mean, that if we want to receive value of some attribute
> from json application server, we must
> send one at first ?

No, it means we won't send the contents of the reply, control, proxy*, coa*, dm* lists. Only request.

-Arran

Arran Cudbard-Bell
a.cudbardb at networkradius.com

Technical consultant and solutions architect

15 Ave. du Granier, Meylan, France
+33 4 69 66 54 50