Standardised JSON VP list format

[Ruslan Shevchenko]

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 ?]


) 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 ?

  Let we have client, which send DHCP Offer message to radius.  Radius
must response with IP address,
which allocated from pool.  Of course incoming message does not
contains YOU_IP_ADDRESS attribute.
So, it will be impossible to request ip address from json server, or I
miss something ?


On Tue, Nov 8, 2011 at 3:32 PM, Arran Cudbard-Bell
<a.cudbardb at freeradius.org> wrote:
> Hi All,
> 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.
>
> Outbound (request):
> {
> "<attribute>":{
> type:"<type>" , # RADIUS or internal attribute type
> value:[<values>] # Always an array, may contain string, integer, float, JSON
> object (nested VP)
> },
> "User-Name":{
> type:"string",
> value:["user at example.org"]
> }
> }
> Inbound (response):
> {
> "[qualifiers:]<attribute>":{
> op:"<operator>", # One of the standard update construct operators
> value:<value> # May be array (multivalued, or nested vps (JSON object)),
> value or JSON object (nested VP)
> },
> # Alternative
> "[qualifiers:]<attribute>":<value> # Value may be anything but a JSON
> object, array values may still hold multiple JSON objects
> }
> All values will be XLATd.
> I'm thinking for the response, maybe two optional bools (for the expanded
> JSON object format):
> no_xlat -  where no_xlat:true disables xlat expansion
> is_json - where is_json:true disables JSON parsing of the value (you can
> write JSON structure to an attribute for later parsing)
> Thoughts?
> If we can decide on a standard format, future modules will be required to
> implement it if they're just bridges to an external service (and the
> external service does not have predefined JSON structures).
> 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.
> -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
>
>
>
>
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/devel.html
>